Reconnexion/ng-eventually
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: les paquets ng-org rattrapent le deploiement, et la lecture vive demarre

Browse Source
This commit is contained in:
Sylvain Duchesne
2026-09-21 11:02:08 +02:00
parent 4a4e6af337
commit 82769c4939
6 changed files with 34 additions and 81 deletions
Download Patch File Download Diff File Expand all files Collapse all files
packages/polyfill/e2e/orm-live-entry.ts
+22 -17
View File
@@ -250,19 +250,26 @@ async function seededTripleCount(doc: Nuri, subject: string): Promise<number> {
/**
* CHARACTERISATION of the deployed broker's `orm_start_graph` ARITY.
*
* The failure the runner reports names a parameter — `config` — that the ORM does not
* send and that `nextgraph-rs` at the read commit does not declare. Two upstream
* arrangements could put one there, and they differ by POSITION:
* The failure the runner reports named a parameter - `config` - that the client of
* the day did not send. Two upstream arrangements could put one there, and they differ
* by POSITION:
* - config LAST, after the callback (upstream 2026-04-12 to 2026-04-21) — an
* unsupplied `config`, never a Function;
* - config at index 4, BEFORE the callback — the 5-argument call from `@ng-org/orm`
* then lands its callback exactly there, which is what the error describes.
* - config at index 4, BEFORE the callback: the 5-argument call of the client of
* the day then lands its callback exactly there, which is what the error described.
*
* So this calls the SDK member directly with an empty config in position 4. It does not
* go through the ORM, which is fixed at five arguments — this is the one question the
* ORM cannot ask. The app-side proxy will mistake the `{}` for the stream callback, so
* nothing usable comes back; what is being read is only whether the engine still
* refuses on `config`.
* THE UPDATE ANSWERED THAT QUESTION. `@ng-org/web@0.1.2-alpha.14` declares six
* arguments with `config` at index 4 and routes the stream callback from index 5
* (`dist/ngweb.js`: `orm_start_graph: 5`), and `@ng-org/orm@0.1.2-alpha.21` sends six
* to match (`dist/connector/RdfOrmSubscription.js:159`). So the second arrangement was
* the right reading, and the ordinary `liveStart` path now exercises it.
*
* This is therefore kept as a FALLBACK, not as the live question: the runner only asks
* it when `liveStart` did not become ready, to say whether the engine still refuses on
* `config` when the client no longer can be blamed. It calls the SDK member directly
* rather than through the ORM. The app-side proxy takes index 5 as the stream callback,
* so the `{}` at index 4 is read as a config and nothing usable comes back; what is
* being read is only whether the start is refused.
*/
async liveStartWithConfig() {
const s = await sessionReady;
@@ -273,14 +280,12 @@ async function seededTripleCount(doc: Nuri, subject: string): Promise<number> {
"store",
undefined,
)) as Nuri;
// Six arguments against a declaration that has five: the declaration describes the
// arity of the PUBLISHED client, and the arity of the DEPLOYED engine is the question.
// Widened through `unknown`, never `any` — the call is deliberate, not unchecked.
const startGraph = realNg.orm_start_graph as unknown as (
...a: unknown[]
) => Promise<unknown>;
// Called against the PUBLISHED declaration, which now has these six arguments, so the
// widening this used to need is gone: the arity is checked here rather than asserted.
// What remains unknowable at compile time is the DEPLOYED engine's arity, which is
// the question this asks.
try {
await startGraph([doc], [], LIVE_SHAPE, s.session_id, {}, () => {});
await realNg.orm_start_graph([doc], [], LIVE_SHAPE, s.session_id, {}, () => {});
return { doc, error: null };
} catch (e) {
return { doc, error: e instanceof Error ? e.message : String(e) };