You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
I was testing 4d751f2 and noticed that if Compactor is run with Read Only permission for blocks Long Term Storage (in my case it was GCS bucket) the only time it gets reported in the logs is upon startup, when blocks_cleaner routine is called (see logs shared below).
Later, when Compactor wants to write something to LTS (in my case it was a no compaction mark) it fails, but does not report it in the logs neither stops the process. In the result it loops endlessly without a visible cause. I assume the similar problem might occur ie. when writing a deletion mark.
I think a change should be introduced to either:
make Compactor fail upon startup if it cannot write to LTS or
report to logs every time it fails to write to LTS (ie. upon trying to create no compaction / deletion mark) or
make it fail after it cannot write to LTS (later than on startup)
This issue has been automatically marked as stale because it has not had any activity in the past 60 days. It will be closed in 15 days if no further activity occurs. Thank you for your contributions.
Describe the bug
I was testing 4d751f2 and noticed that if Compactor is run with Read Only permission for blocks Long Term Storage (in my case it was GCS bucket) the only time it gets reported in the logs is upon startup, when
blocks_cleaner
routine is called (see logs shared below).Later, when Compactor wants to write something to LTS (in my case it was a no compaction mark) it fails, but does not report it in the logs neither stops the process. In the result it loops endlessly without a visible cause. I assume the similar problem might occur ie. when writing a deletion mark.
I think a change should be introduced to either:
To Reproduce
Steps to reproduce the behavior:
skip_blocks_with_out_of_order_chunks_enabled
is enabledExpected behavior
Upon failing to create a no compaction mark in LTS there is an error logged in logs and / or the process fails.
Environment:
Storage Engine
Additional Context
logs when run with RO permissions:
logs when run with RW permissions:
how docker is run:
docker_run_config.yaml:
Related also to #4692 and #4677
The text was updated successfully, but these errors were encountered: