-
Notifications
You must be signed in to change notification settings - Fork 457
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
storage-client: don't panic if reading Kafka secret fails #18563
Conversation
@philip-stoev would you like to try to test this somehow? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change itself looks good! @philip-stoev We don't yet have infra for futzing with the secrets store for tests, do we?
Let me cook a test today, give me 1 hour. |
A fix is needed on the postgres side too:
|
Do you have a test ready that provokes this? It seems |
4edfe55
to
f62563c
Compare
Updated with a fix for PostgreSQL too. @petrosagg you may want to take a look. The |
I am terribly sorry, but there is still a panic when trying a
|
I pushed a cloudtest as a separate commit -- it currently fails because of the panic reported above. |
Thanks for the test, @philip-stoev. Aljoscha: I likely need someone else to take this over. Is someone from storage available? |
I'll take it over |
35c5651
to
d292b5c
Compare
I rebased and fixed up based on the latest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Surfaces changes look good!
c1005bc
to
d524b5f
Compare
The surrounding code paths have been sufficiently refactored such that it is now possible to gracefully return an error here. Fix MaterializeInc#18438.
795b615
to
f0ac9df
Compare
@philip-stoev I fixed up our behaviour and the cloud test:
@benesch At first glance, it might seem bad that you can't drop a cluster when secrets are not accessible. On the other hand, I think users should never see this because they normally can't mess with secret storage. The other option is to go through with dropping the cluster. This will mean, however, that we leak the postgres resources that we are trying to clean up using those missing secrets. wdyt? |
I would much rather stick with the behavior that you've already got (not dropping a cluster with inaccessible secrets)! |
Thanks very much for pushing this over the line. |
Oh yes, absolutely! Sorry if this wasn't clear from how I described it. |
It was! I was just trying to express enthusiasm for your choice! |
The surrounding code paths have been sufficiently refactored such that it is now possible to gracefully return an error here.
Fix #18438.
Motivation
Checklist
$T ⇔ Proto$T
mapping (possibly in a backwards-incompatible way) and therefore is tagged with aT-proto
label.