fix(tm1): validate results-CSV header to prevent measure drift (#169)#170
Merged
Merged
Conversation
}rushti.load.results maps CSV columns to TI variables positionally. A process built before 2.3.0 (pre-chore column) and left in place after an in-place rushti upgrade silently shifted every value from chore/ parameters onward into the next measure. Read the header row (asciiHeaderRecords=0) and validate each column against the variable it feeds in the metadata tab; ProcessQuit with the offending columns on mismatch instead of writing scrambled data. The check is generated from PROCESS_VARIABLES so it can't drift from the CSV contract. Verified end-to-end on TM1 v11 and v12. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
MariusWirtz
added
the
release:patch
MariusWirtz
approved these changes
Jul 9, 2026
| `rushti build --tm1-instance X`** to refresh the process (and additively add | ||
| any new measure element) — the guard only turns future drift into a clear | ||
| error, it does not repair an already-stale process. Existing rows written | ||
| under the wrong measures should be cleared and the workflow re-run. |
Collaborator
There was a problem hiding this comment.
Just added a release tag to this PR
I think this section is no longer appropriate under Unreleased
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Fixes #169 — execution results written to the wrong TM1 measures.
}rushti.load.resultsmaps result-CSV columns to its TI variables by position (asciiHeaderRecords=1simply skipped the header). In 2.3.0 thechoremeasure was inserted at column 7 (betweenprocessandparameters). A cube/process built by a pre-2.3.0 rushti and then upgraded in place without re-runningrushti buildends up with a CSV that has achorecolumn its stale TI doesn't read — so every value fromchore/parametersonward is read one position early and written to the next measure over (parameters → status,status → start_time, …). Exactly the symptom reported, and it silently scrambles rather than erroring.Fix
asciiHeaderRecords=0) so the metadata tab can see it.ProcessQuit(fail loudly) instead of writing scrambled data.PROCESS_VARIABLES, so it can't drift from the CSV column contract.The guard only turns future drift into a clear error — the remedy for an already-stale deployment is still to re-run
rushti build --tm1-instance <inst>(now documented in the migration guide + changelog).Verification
Unit suite green (793 passed) with 5 new contract tests. Verified end-to-end on live TM1 v11 (11.8) and v12 (12.5):
QuitCalled)Type of Change
Checklist
🤖 Generated with Claude Code