Streamline error events #10

New Issue

spivee · 2025-06-24T09:37:39+09:00

spivee commented

2025-06-24 09:37:39 +09:00

When a worker produces a cycle, or no solution, a {result, #{info => Result}} event is produced.

When a worker fails to open, or produces some other error, (such as exit statuses, once they are merged,) three events are produced:

First, a {result, #{info => {error, Reason}}} event is produced, since results all go through the same path,
then an {error, #{error => cannot_start_worker, data => {error, Reason}}} event is produced, representing an error in the process of trying to report the result to the hive server
finally, the EXIT signal from the worker process is trapped, and a {error, #{error => worker_error, data => Reason}} event is produced

The first of these should simply be removed - there is no point allowing people to subscribe/unsubscribe to events if errors are going to appear in every one.

The last two are redundant because of paradigm-mixing, try catch is used, and exit trapping of a short-lived worker process is also used. We only need to do one of these two error detection mechanisms, and so we should certainly only report errors for one.

The data => {error, Reason} format is dreadful, though. Whichever style of error detection is used, data => Reason should be the output.

The distinction between cannot_start_worker and worker_error is nice, but isn't useful if we always report both. Reporting failure to start separately from failure after starting requires refactors in gmhive_worker, which might be worth doing also.

There are other sources of redundant events, too, like the informative HTTP 404 errors in one message, that get redundantly reported as a second "connection failed" message with no response status code... This results in users seeing "connection failed" and thinking their internet is down, which has confused the community to the point where we don't see some bugs that we want to see.

When a worker produces a cycle, or no solution, a {result, #{info => Result}} event is produced. When a worker fails to open, or produces some other error, (such as exit statuses, once they are merged,) three events are produced: - First, a {result, #{info => {error, Reason}}} event is produced, since results all go through the same path, - then an {error, #{error => cannot_start_worker, data => {error, Reason}}} event is produced, representing an error in the process of trying to report the result to the hive server - finally, the EXIT signal from the worker process is trapped, and a {error, #{error => worker_error, data => Reason}} event is produced The first of these should simply be removed - there is no point allowing people to subscribe/unsubscribe to events if errors are going to appear in every one. The last two are redundant because of paradigm-mixing, try catch is used, and exit trapping of a short-lived worker process is also used. We only need to do one of these two error detection mechanisms, and so we should certainly only report errors for one. The `data => {error, Reason}` format is dreadful, though. Whichever style of error detection is used, `data => Reason` should be the output. The distinction between `cannot_start_worker` and `worker_error` is nice, but isn't useful if we always report both. Reporting failure to start separately from failure after starting requires refactors in gmhive_worker, which might be worth doing also. There are other sources of redundant events, too, like the informative HTTP 404 errors in one message, that get redundantly reported as a second "connection failed" message with no response status code... This results in users seeing "connection failed" and thinking their internet is down, which has confused the community to the point where we don't see some bugs that we want to see.

spivee added the

pig lipstick

label 2025-06-24 09:37:39 +09:00

spivee self-assigned this 2025-06-24 09:37:39 +09:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: QPQ-AG/gmhive_client#10