Skip to content

Conversation

@bkirwi
Copy link
Contributor

@bkirwi bkirwi commented Sep 2, 2025

Motivation

Trying to narrow down the location of a filter-pushdown issue.

Tips for reviewer

These logs would have been pretty hazardous to produce before, but ought to be okay with the new redaction.

Checklist

  • This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
  • This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
  • If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
  • If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
  • If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

If auditing is set to 100%, disabling this flag will report any filter
pushdown errors without any stability or correctness risk. (Since we
always use the result of the normal interpretation path.)

I considered making this conditional on auditing being at 100%, but I
think it's more useful to keep them separate in case we ever have a bug
in the audit mechanism itself. However, I've added some clear
expectation in the flag description to help ward against misuse.
@bkirwi bkirwi marked this pull request as ready for review September 3, 2025 19:10
@bkirwi bkirwi requested review from a team as code owners September 3, 2025 19:10
Copy link
Member

@DAlperin DAlperin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Makes me wonder if we have any mechanisms to make sure dyncfgs move in lockstep with each other? i.e. audit percentage with audit panic?

@bkirwi
Copy link
Contributor Author

bkirwi commented Sep 3, 2025

Makes me wonder if we have any mechanisms to make sure dyncfgs move in lockstep with each other?

There are - three, I guess:

  1. We'll often express the relationship in the code - only enabling a behaviour if a flag and its prerequisite are set.
  2. LaunchDarkly has a concept of prerequisites, apparently. I've never used it.
  3. Sometimes we'll just be careful.

Since I could imagine a case where I'd want to enable this flag independently, I decided to go with strategy 3 here. But I think all of them are plausible for different situations...

@bkirwi bkirwi merged commit 5b0f392 into MaterializeInc:main Sep 8, 2025
129 checks passed
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