Skip to content

Conversation

bkirwi
Copy link
Contributor

@bkirwi bkirwi commented Oct 10, 2025

Motivation

Running these in debug and release mode, or with different env vars set, can result in different output due to our debug data redaction. It's a little weird that our debug representations filter up into user-facing SQL output like this - it seems like debug should normally be an internal thing - but anyways setting this env var will ensure that we get the full unredacted output from our SLTs and also run the maximum of assertions.

No reason not to get the additional coverage, plus this makes results
more consistent between environments. (SLTs sometimes include debug
info, which is a bit questionable, but does happen...)
@ggevay
Copy link
Contributor

ggevay commented Oct 11, 2025

The most recent discussion on this: https://github.com/MaterializeInc/database-issues/issues/8097#issuecomment-2720688239

So, if I understand correctly, the change that this PR makes is that when running the slts locally, MZ_SOFT_ASSERTIONS will be set. This makes sense to me: I often have to manually set this when running --optimized or --release builds locally, and we won't need to do that after this PR. (CI already sets this.)

Copy link
Contributor

@def- def- left a comment

Choose a reason for hiding this comment

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

Hm, that's not great. I agree with the issue that it shouldn't matter whether this env variable is set or not, but as a quick band aid this change seems fine.

@bkirwi bkirwi marked this pull request as ready for review October 13, 2025 18:56
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.

3 participants