Skip to content

Less strict throwing of runtime error#52

Open
tomdeblauwe wants to merge 1 commit intofacontidavide:mainfrom
tomdeblauwe:less_strict_runtime_errors
Open

Less strict throwing of runtime error#52
tomdeblauwe wants to merge 1 commit intofacontidavide:mainfrom
tomdeblauwe:less_strict_runtime_errors

Conversation

@tomdeblauwe
Copy link
Contributor

While encoding, sometimes there can be a timeout in the compressionWorker but actually, it's not that anything is broken, it's just that the system is very busy at startup. So throwing a runtime error is too much because there no possible option to disable it, or catch it: a try catch around the encode function won't do it because it is in another thread when using compression.

While encoding, sometimes there can be a timeout in the
compressionWorker but actually, it's not that anything is
broken, it's just that the system is very busy at startup.
So throwing a runtime error is too much because there no
possible option to disable it, or catch it: a try catch
around the encode function won't do it because it is in
another thread when using compression.

Signed-off-by: tomdeblauwe <tom.deblauwe@zygo.be>
@facontidavide
Copy link
Owner

the reason why I originally added that is that this is NOT supposed to happen and it is generally a signal that we are ingesting data to compress faster than we can compress it.

Probably the right solution is also to add a maximum memory / buffer size and drop older messages that we can not keep up with

@facontidavide facontidavide self-assigned this Feb 4, 2026
@tomdeblauwe
Copy link
Contributor Author

What would also be nice is that you can choose not to use a thread. Now that is only possible when not using compression. So would be nice to allow this even when using compression.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants