The two lineage findings, from review 928 on #481.
The direction label echoed a normalised word (FORWARDS/REVERSE) where the estate prints &direction Lineage for <b>&col</b> - the caller's own word - and the client sends FORWARD. The label now echoes the request.
COLNAME fell back to the requested coluri when the cache held no row, so the breadcrumb printed OMSOBJ:Column\A5... where a column name belongs. The estate's COLNAME is empty in that case and the template skips an empty one, so the fallback is now empty rather than the URI.
Both are pinned in lineage.test.js and both fail with the service file reverted (5 pass / 2 fail) and pass here (7 pass).
The site-mode libref finding is not in this PR, deliberately. It is a different problem from the two above: makedata moves the control library to the clock name while stageSubmission still writes under DC_JSLIB and the seeded MPE_TABLES rows name DC_JSLIB while viewlibs answers with the clock libref - so the fix is a decision about which library is authoritative on a site-mode estate, applied across the writers and the seeded registry, not a string change in one service. Your reproduction is exact and I am not going to paper over it with a fallback that makes the edit cycle pass while the registry still disagrees.
The two lineage findings, from review 928 on #481.
- **The direction label** echoed a normalised word (`FORWARDS`/`REVERSE`) where the estate prints `&direction Lineage for <b>&col</b>` - the caller's own word - and the client sends `FORWARD`. The label now echoes the request.
- **`COLNAME`** fell back to the requested `coluri` when the cache held no row, so the breadcrumb printed `OMSOBJ:Column\A5...` where a column name belongs. The estate's `COLNAME` is empty in that case and the template skips an empty one, so the fallback is now empty rather than the URI.
Both are pinned in `lineage.test.js` and both fail with the service file reverted (5 pass / 2 fail) and pass here (7 pass).
The site-mode libref finding is not in this PR, deliberately. It is a different problem from the two above: `makedata` moves the control library to the clock name while `stageSubmission` still writes under `DC_JSLIB` and the seeded `MPE_TABLES` rows name `DC_JSLIB` while `viewlibs` answers with the clock libref - so the fix is a decision about which library is authoritative on a site-mode estate, applied across the writers and the seeded registry, not a string change in one service. Your reproduction is exact and I am not going to paper over it with a fallback that makes the edit cycle pass while the registry still disagrees.
Two parity gaps in fetchcollineage, both visible on any lineage screen:
- The label said FORWARDS or REVERSE while the estate prints "&direction
Lineage for <b>&col</b>" - what the caller sent. The client sends FORWARD
(lineage.component.ts:352), so the mock was showing a word nobody sent.
- With nothing cached for the column, askedColumn fell back to the requested
coluri, so the breadcrumb printed "OMSOBJ:Column\A5..." where a column name
belongs. The estate's COLNAME is empty in that case and the client's template
skips an empty one.
Both pinned in lineage.test.js, and both cases fail with the service file
reverted (5 pass, 2 fail) and pass here (7 pass).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The two lineage findings, from review 928 on #481.
FORWARDS/REVERSE) where the estate prints&direction Lineage for <b>&col</b>- the caller's own word - and the client sendsFORWARD. The label now echoes the request.COLNAMEfell back to the requestedcoluriwhen the cache held no row, so the breadcrumb printedOMSOBJ:Column\A5...where a column name belongs. The estate'sCOLNAMEis empty in that case and the template skips an empty one, so the fallback is now empty rather than the URI.Both are pinned in
lineage.test.jsand both fail with the service file reverted (5 pass / 2 fail) and pass here (7 pass).The site-mode libref finding is not in this PR, deliberately. It is a different problem from the two above:
makedatamoves the control library to the clock name whilestageSubmissionstill writes underDC_JSLIBand the seededMPE_TABLESrows nameDC_JSLIBwhileviewlibsanswers with the clock libref - so the fix is a decision about which library is authoritative on a site-mode estate, applied across the writers and the seeded registry, not a string change in one service. Your reproduction is exact and I am not going to paper over it with a fallback that makes the edit cycle pass while the registry still disagrees.Lighthouse
#/home/tables#/editor/DC996664.MPE_X_TEST#/view/data#/view/data/DC996664#/view/data/DC996664.MPE_X_TEST#/view/usernav/groups#/view/usernav/groups/1#/view/usernav/users/1#/home/excel-maps#/home/excel-maps/BASEL-CR2#/home/multi-load#/review/submitted#/review/approve#/review/history#/stage/DC20221006T142649516_059582_7169#/review/submitted/DC20221006T142649516_059582_7169#/systemLowest accessibility score: 0.87 (the gate is a median of 0.85 while issue 497 is open).
Run: https://git.datacontroller.io/dc/dc/actions/runs/3542