@ibgib/core-gib 0.1.27 → 0.1.29

package/src/sync/sync-saga-message/sync-saga-message-types.mts

@@ -6,6 +6,7 @@ import { SyncStage } from "../sync-constants.mjs";
 import { SyncMode, SyncConflictStrategy, } from "../sync-types.mjs";
 import { SYNC_SAGA_MSG_ATOM } from "./sync-saga-message-constants.mjs";
 import type { getDeltaDependencyGraph } from '../../common/other/graph-helper.mjs';
+import type { SyncSagaContextIbGib_V1, SyncSagaContextData_V1 } from '../sync-saga-context/sync-saga-context-types.mjs';
 
 export interface SyncSagaMessageIb_V1 {
     atom: typeof SYNC_SAGA_MSG_ATOM;
@@ -145,28 +146,16 @@ export interface SyncSagaConflictInfo {
 export interface SyncSagaMessageAckData_V1 extends SyncSagaMessageData_V1 {
     stage: typeof SyncStage.ack;
     deltaRequestAddrInfos: SyncSagaRequestAddrInfo[];
-    pushOfferInfos: SyncSagaPushOfferInfo[];
     /**
-     * Map of group keys (TJP addr/constant addr) to list of known addresses
-     * in that timeline.
-     *
-     * This will be used by Sender to calculate differential payloads. So
-     * when the sender goes to get the dependency graph of its tip ibgib,
-     * it can skip all of the addrs in this.
-     *
-     * For example, say sender has A^5 and receiver only has A^3. Sender
-     * will see in this map { [A^0]: [A^0, A^1, A^2, A^3] } and know that
-     * it needs all of the dependencies of A^5 (including A^4), but it does
-     * NOT need to send A^0-A^3 (and dependencies) because receiver already has
-     * these.
+     * Infos regarding ibgibs that the receiver (generator of this ack)
+     * knows/believes that the sender does NOT have (after looking at knowledge
+     * vector of sender).
      *
-     * ## notes
+     * This includes addrs that will correspond to the context.payloadAddrsDomain
      *
-     * I dislike this name in my rewrite/cleanup of this algorithm. However, I'm
-     * keeping it and am using it right now in handleInitFrame for including
-     * the receiver's latest addr/tip for the deltaReqAddrs. But really, I should
+     * ## note
      */
-    // knowledgeVector?: { [tjpAddr: string]: string[] };
+    pushOfferInfos: SyncSagaPushOfferInfo[];
     /**
      * List of identified conflicts.
      *
@@ -194,6 +183,12 @@ export interface SyncSagaMessageDeltaData_V1 extends SyncSagaMessageData_V1 {
     /**
      * Domain ibgib addresses (actual user data being synced).
      * These go to tempSpace ONLY until final commit.
+     *
+     * NOTE: There is also a payloadAddrsDomain on the actual context itself on
+     * {@link SyncSagaContextData_V1}.
+     * NOTE: There is also payload info in {@link SyncSagaMessageAckData_V1}
+     * in {@link SyncSagaMessageAckData_V1.pushOfferInfos}. Not quite as elegant
+     * as I want it to be but there ya go.
      */
     payloadAddrsDomain?: string[];
 }

package/src/sync/sync-types.mts

@@ -9,7 +9,7 @@ import { IbGibSpaceAny } from "../witness/space/space-base-v1.mjs";
 import { MetaspaceService } from "../witness/space/metaspace/metaspace-types.mjs";
 import { SyncPeerWitness } from "./sync-peer/sync-peer-types.mjs";
 import { FlatIbGibGraph } from "../common/other/graph-types.mjs";
-import { SyncSagaConflictInfo } from "./sync-saga-message/sync-saga-message-types.mjs";
+import { SyncSagaConflictInfo, SyncSagaMessageIbGib_V1 } from "./sync-saga-message/sync-saga-message-types.mjs";
 
 
 // #region SyncMode
@@ -54,54 +54,47 @@ export function isValidSyncConflictStrategy(strategy: string): strategy is SyncC
 }
 // #endregion SyncConflictStrategy
 
-// #region SyncExecutionContext
-export const SYNC_EXECUTION_CONTEXT_SENDER = 'sender';
-export const SYNC_EXECUTION_CONTEXT_RECEIVER = 'receiver';
-export type SyncExecutionContext =
-    | typeof SYNC_EXECUTION_CONTEXT_SENDER
-    | typeof SYNC_EXECUTION_CONTEXT_RECEIVER
+// #region SyncSagaFrameOrigin
+export const SYNC_SAGA_FRAME_ORIGIN_SENDER = 'sender';
+export const SYNC_SAGA_FRAME_ORIGIN_RECEIVER = 'receiver';
+export type SyncSagaFrameOrigin =
+    | typeof SYNC_SAGA_FRAME_ORIGIN_SENDER
+    | typeof SYNC_SAGA_FRAME_ORIGIN_RECEIVER
     ;
 /**
- * if the current code execution is executing on the original sender (the
- * initiator of the sync saga operation) or the other party, the "receiver" (the
- * one responding).
+ * if the frame was created by the original sender (the initiator of the sync
+ * saga operation) or the other party, the "receiver" (the one responding).
  *
  * This is driven by looking at the latest value of `sagaFrame.data.n` value.
- *
- * NOTE: This is not to be confused with the sync saga context ibgib, which is
- * something else entirely. That is the transport wrapper ibgib around the saga.
- * this is strictly the enum for where the code is executing.
  */
-export const SyncExecutionContext = {
+export const SyncSagaFrameOrigin = {
     /**
-     * The current code is executing on the initial location that started the
-     * sync.
+     * The frame was created on the initial location that started the sync.
      */
-    sender: SYNC_EXECUTION_CONTEXT_SENDER,
+    sender: SYNC_SAGA_FRAME_ORIGIN_SENDER,
     /**
-     * The current code is executing on the receiving end, which is either a
-     * physically different location or is the logical "receiver" of an
-     * in-memory sync execution.
+     * The frame was created on the receiving end, which is either a physically
+     * different location or is the logical "receiver" of an in-memory sync
+     * execution.
      */
-    receiver: SYNC_EXECUTION_CONTEXT_RECEIVER,
-} satisfies { [key in SyncExecutionContext]: SyncExecutionContext };
-export const SYNC_EXECUTION_CONTEXT_VALID_VALUES = Object.values(SyncExecutionContext);
-export function isValidSyncExecutionContext(executionContext: string): executionContext is SyncExecutionContext {
-    return SYNC_EXECUTION_CONTEXT_VALID_VALUES.includes(executionContext as SyncExecutionContext);
+    receiver: SYNC_SAGA_FRAME_ORIGIN_RECEIVER,
+} satisfies { [key in SyncSagaFrameOrigin]: SyncSagaFrameOrigin };
+export const SYNC_SAGA_FRAME_ORIGIN_VALID_VALUES = Object.values(SyncSagaFrameOrigin);
+export function isValidSyncSagaFrameOrigin(sagaFrameOrigin: string): sagaFrameOrigin is SyncSagaFrameOrigin {
+    return SYNC_SAGA_FRAME_ORIGIN_VALID_VALUES.includes(sagaFrameOrigin as SyncSagaFrameOrigin);
 }
 // #endregion SyncConflictStrategy
 
 export interface NextSagaFrameInfo_Frame {
     frame: SyncIbGib_V1;
     payloadIbGibsDomain?: IbGib_V1[];
-    // conflictInfos?: SyncSagaConflictInfo;
-    responseWasNull?: undefined;
+    sagaComplete?: undefined;
 }
-export interface NextSagaFrameInfo_Null {
+export interface NextSagaFrameInfo_SagaComplete {
     frame?: never;
     payloadIbGibsDomain?: never;
     conflictInfos?: never;
-    responseWasNull: true;
+    sagaComplete: true;
 }
 /**
  * Result of handling a saga frame.
@@ -112,8 +105,7 @@ export interface NextSagaFrameInfo_Null {
  * defined, thus the discriminated union type.
  */
 export type NextSagaFrameInfo =
-    NextSagaFrameInfo_Frame | NextSagaFrameInfo_Null;
-
+    NextSagaFrameInfo_Frame | NextSagaFrameInfo_SagaComplete;
 
 export interface HandleSagaResponseContextResult_Base {
     /**
@@ -207,7 +199,8 @@ export interface SyncSagaInfo {
 
 export interface SyncSagaFrameDependencyGraph {
     sagaIbGib: SyncIbGib_V1;
-    msgStones: IbGib_V1[];
+    // msgStones: IbGib_V1[];
+    msgStones: SyncSagaMessageIbGib_V1[];
     identities: KeystoneIbGib_V1[];
 }
 

package/tmp.md

@@ -1,62 +1,170 @@
-Great! Ty for going through that! In crafting my response for you, I have since updated the libs\core-gib\src\sync\README.md file, so please re-read that file for me. There were several inaccuracies and it is much improved.
-
-Now for your questions. Let's get to them!
-
-## foundational
-
-1. I don't know if the conflict merging aspect is working well or not. I have implemented a similar optimistic strategy before in a previous sync prototype that worked well (though that implementation was very slow). This approach is the same, except two additions: a) naive text merge if the transform targets `data.text`, and b) adding "graft info" (libs\core-gib\src\sync\graft-info) to the timeline after the merge so that original divergent states aren't lost. Both of these should be straightforward though. The main problem right now is trying to isolate the various stages of the "ping-pong" exchange.
-
-2. Tjp is fully implemented and has been for several years now. Including the tjpGib in the full address, instead of just using a bare hash, has proved immensely useful (and as you know, this is completely novel/innovative as there is no other protocol that does this).
-
-3. We originally had control and domain payloads grouped together and we had to separate them. However, this was done poorly by the original agent, and may yet still be incomplete. AFAICT though, the most recent attempt at completing the separation was successful. The current blocking issue is that it's hard to tell what is causing the test in sync-conflict.respec.mts to fail. The logging gets too verbose and is hard to track throughout the entire transaction. 
-
-4. We are deferring integrating the session keystones until we get the non-keystone workflow going.
-
-## current state
-
-5. The immediate symptom is the test in `sync-conflict.respect.mts` is failing. You can see the output of the most recent run in C:\Users\billm\antigravity\ibgib\libs\core-gib\test_output.log .  But it is a coarse test, and really, it's hard to even read the test itself. But it's also hard to try to create more granular unit tests, though that may be the right path forward.
-
-6. AFAICT the v16 implementation plan has been partially implemented. For example, `handleAckFrame` in `saga-coordinator.mts` still has not had the `payloadIbGibs` separated properly, i.e., there is still a variable called `payloadIbGibs`, despite us mandating that there should be NO references to this. Every instance of that string should be separated into control and domain payload ibgibs. It's actually looking like that `handleAckFrame` is not right anymore, though the libs\core-gib\src\sync\sync-innerspace-dest-ahead.respec.mts test is still passing so it's not completely wrong. But if you read through that method, you'll see it's not right and there is a not-implemented error line in there.
-
-The same is true for `payloadAddrs`, which should NOT exist anywhere. But it still is on `SyncDeltaData`. It should not be "deprecated", it should have been removed and references to it should have led us to more places to complete the separation of control and domain addrs.
-
-7. I think part of the problem is that our implementation plans have been too complex and we didn't follow through to ensure that each and every piece was taken care of. Perhaps a todo/checklist would be more appropriate. But I devote quite a bit of time to refine the implementation plan, and then the nuances get lost. So we have a bunch of messy, half-completed code. Granted, this is a relatively complex sync algorithm, but it should absolutely be feasible.
-
-But let me speak to your specific questions on this:
-
-* Too many iterations/refactorings without clear direction?
-  * I don't mind the iterations. I mind thinking that something is complete and it is not. This is partially my fault in not breaking it down and unit testing it more granularly, but that would add a huge amount of overhead, and what inevitably happens is we troubleshoot the tests and not the code.
-* Type boundaries bleeding between concerns?
-  * Our types are pretty well created by this point. 
-* The polling mechanism feeling hacky?
-  * No, the polling mechanism is fine.
-* Race conditions or timing issues?
-  * There have been no race conditions that I know of.
-
-I had previous success with Antigravity on other smaller tasks, but this one seems to have been a little too advanced for the Gemini 3 High model. Your model seems to be performing better, however we hit the smaller context window rather quickly. Overall, I am just trying not to have to go through every single LoC myself, though it's looking like that is more and more likely.
-
-Here is another example I've come across that is messy. Look at the following code found in `sync-saga-coordinator.mts`:
-
-```
-// 4. EXECUTE SAGA LOOP (FSM)
-// Inject tempSpace into peer so it can pull control payloads to the right place
-if ('opts' in peer && peer.opts) {
-    (peer.opts as any).senderTempSpace = tempSpace;
-}
-```
-
-This is terrible! This is a hack so that if we have a `SyncPeerInnerspace_V1`, we set its temp space. This is "messy" to say the least.
-
-### sync test results
-
-* libs\core-gib\src\sync\sync-innerspace.respec.mts PASSING
-* libs\core-gib\src\sync\sync-innerspace-constants.respec.mts PASSING
-* libs\core-gib\src\sync\sync-innerspace-dest-ahead.respec.mts PASSING
-* libs\core-gib\src\sync\sync-innerspace-deep-updates.respec.mts PASSING
-* libs\core-gib\src\sync\sync-innerspace-multiple-timelines.respec.mts PASSING
-* libs\core-gib\src\sync\sync-innerspace-partial-update.respec.mts PASSING
-* libs\core-gib\src\sync\sync-conflict.respec.mts FAILING
-
-## how you can help
-
-All of the simpler tests that don't require a Delta frame back and forth (short back-and-forth to resolve the conflict) are all passing. I _think_ that the merge logic itself is fine, though I haven't gone through that with a fine-tooth comb yet. To me, the most obvious problem right now is that the mechanism for passing domain ibgibs back and forth is not working. For example, look in libs\core-gib\src\sync\sync-saga-coordinator.mts for `srcGraph`. That was added early on in the code sketch. IIRC, it was supposed to be for the domain ibgibs in the original sender's location. Is that another name for payloadIbGibs, but stored in a map? How does it get populated? How do the payload ibgibs go from the peer to the handle____ methods? So don't do any coding right now. Perhaps this whole conversation will just be you and I talking about the code as I go through it. So just point me to things that you see and I will make changes, because I need to wrap this up in the next 3 days. Do note that I have made some changes since starting this message to you, and it doesn't build at the moment. But overall there are still things that you can just point me to if you just examine the logic.
+[SyncSagaCoordinator][executeLocalCommit] currentExecutionContext: receiver (I: 3add8f8390c89743ae554bd3cc60b826)
+[SyncSagaCoordinator][executeLocalCommit][receiver] history slice: {
+  "sagaIbGib": {
+    "ib": "sync 27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b",
+    "gib": "614E694D3F27A1B636E7344A91A3BA3562D0615A5626BF46EA8D0D4A99ED2EAA",
+    "data": {
+      "n": 0,
+      "timestamp": "Thu, 22 Jan 2026 18:43:36 GMT",
+      "timestampMs": 972,
+      "uuid": "27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b",
+      "conflictStrategy": "abort",
+      "isTjp": true
+    },
+    "rel8ns": {
+      "ancestor": [
+        "sync^gib"
+      ],
+      "syncmsg": [
+        "sync_sagamsg 27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b init^A07224377D6DD1C25F0291F5F67AA5CC2E52B95B6904B4BC8CBCDA198CF4C456"
+      ]
+    }
+  },
+  "msgStones": [
+    {
+      "ib": "sync_sagamsg 27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b init",
+      "gib": "A07224377D6DD1C25F0291F5F67AA5CC2E52B95B6904B4BC8CBCDA198CF4C456",
+      "data": {
+        "timestamp": "Thu, 22 Jan 2026 18:43:36 GMT",
+        "timestampMs": 956,
+        "sagaId": "27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b",
+        "stage": "init",
+        "knowledgeVector": {},
+        "mode": "sync",
+        "stones": [
+          "constant_c1^2B4B05537B40B9B5FC501E58EE9256B6F33259BA629A4633113B8104C1B5B08C"
+        ],
+        "uuid": "4a4acb6d42d99168e20e899931bed0291450ec3dfaecfdcab09ed64606eff43b"
+      },
+      "rel8ns": {
+        "ancestor": [
+          "sync_sagamsg^gib"
+        ]
+      }
+    }
+  ],
+  "identities": []
+} (I: e5a9436fb66b0df3183bd6d81be2ca26)
+[SyncSagaCoordinator][executeLocalCommit][receiver] history slice: {
+  "sagaIbGib": {
+    "ib": "sync 27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b",
+    "gib": "7F787D985C836D0C340155AD38E18F6A7F3A76AA7805FD040EBAFABC045354E9.614E694D3F27A1B636E7344A91A3BA3562D0615A5626BF46EA8D0D4A99ED2EAA",
+    "data": {
+      "n": 2,
+      "timestamp": "Thu, 22 Jan 2026 18:43:37 GMT",
+      "timestampMs": 157,
+      "uuid": "27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b",
+      "conflictStrategy": "abort"
+    },
+    "rel8ns": {
+      "ancestor": [
+        "sync^gib"
+      ],
+      "syncmsg": [
+        "sync_sagamsg 27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b delta^83B967620C334ADCCB6749DBDC9A69CE40284FDC3948D1299CBF8E68DD2F3B40"
+      ],
+      "past": [
+        "sync 27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b^614E694D3F27A1B636E7344A91A3BA3562D0615A5626BF46EA8D0D4A99ED2EAA",
+        "sync 27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b^485E8579F73B991039C636843E19B03BC597E6BF71F48018257FDD3FEDEF5AE2.614E694D3F27A1B636E7344A91A3BA3562D0615A5626BF46EA8D0D4A99ED2EAA"
+      ],
+      "tjp": [
+        "sync 27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b^614E694D3F27A1B636E7344A91A3BA3562D0615A5626BF46EA8D0D4A99ED2EAA"
+      ]
+    }
+  },
+  "msgStones": [
+    {
+      "ib": "sync_sagamsg 27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b delta",
+      "gib": "83B967620C334ADCCB6749DBDC9A69CE40284FDC3948D1299CBF8E68DD2F3B40",
+      "data": {
+        "timestamp": "Thu, 22 Jan 2026 18:43:37 GMT",
+        "timestampMs": 136,
+        "sagaId": "27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b",
+        "stage": "delta",
+        "payloadAddrsDomain": [
+          "constant_c1^2B4B05537B40B9B5FC501E58EE9256B6F33259BA629A4633113B8104C1B5B08C"
+        ],
+        "proposeCommit": false,
+        "uuid": "984932f854d515a22d6dceefb390a3b4500ad3da5eb745c217bea025aa3a12c0"
+      },
+      "rel8ns": {
+        "ancestor": [
+          "sync_sagamsg^gib"
+        ]
+      }
+    }
+  ],
+  "identities": []
+} (I: e5a9436fb66b0df3183bd6d81be2ca26)
+[SyncSagaCoordinator][executeLocalCommit][receiver] history slice: {
+  "sagaIbGib": {
+    "ib": "sync 27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b",
+    "gib": "F83441D677AA434A5A6BB2B071BB91A77FC2D310834602630425B80C310C0062.614E694D3F27A1B636E7344A91A3BA3562D0615A5626BF46EA8D0D4A99ED2EAA",
+    "data": {
+      "n": 4,
+      "timestamp": "Thu, 22 Jan 2026 18:43:37 GMT",
+      "timestampMs": 392,
+      "uuid": "27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b",
+      "conflictStrategy": "abort"
+    },
+    "rel8ns": {
+      "ancestor": [
+        "sync^gib"
+      ],
+      "syncmsg": [
+        "sync_sagamsg 27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b commit^0E66808B115227AA36DCB34AE5B07C85FD89FB8F9AACFBC8B943D276DB1449E0"
+      ],
+      "past": [
+        "sync 27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b^614E694D3F27A1B636E7344A91A3BA3562D0615A5626BF46EA8D0D4A99ED2EAA",
+        "sync 27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b^485E8579F73B991039C636843E19B03BC597E6BF71F48018257FDD3FEDEF5AE2.614E694D3F27A1B636E7344A91A3BA3562D0615A5626BF46EA8D0D4A99ED2EAA",
+        "sync 27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b^7F787D985C836D0C340155AD38E18F6A7F3A76AA7805FD040EBAFABC045354E9.614E694D3F27A1B636E7344A91A3BA3562D0615A5626BF46EA8D0D4A99ED2EAA",
+        "sync 27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b^C5CA645BB939F80F5453D2F20009A52952D878A39F7317A4054B11B8FE4FA7CC.614E694D3F27A1B636E7344A91A3BA3562D0615A5626BF46EA8D0D4A99ED2EAA"
+      ],
+      "tjp": [
+        "sync 27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b^614E694D3F27A1B636E7344A91A3BA3562D0615A5626BF46EA8D0D4A99ED2EAA"
+      ]
+    }
+  },
+  "msgStones": [
+    {
+      "ib": "sync_sagamsg 27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b commit",
+      "gib": "0E66808B115227AA36DCB34AE5B07C85FD89FB8F9AACFBC8B943D276DB1449E0",
+      "data": {
+        "timestamp": "Thu, 22 Jan 2026 18:43:37 GMT",
+        "timestampMs": 372,
+        "sagaId": "27343ef70b00902267f66910704e105aaac6dbd731dd416e2a94dabc9f53307b",
+        "stage": "commit",
+        "success": true,
+        "uuid": "f50c37e8e459d9bf1493a1c9c6c0ebdf31ecf63533cbc94357c3a8773f70fe50"
+      },
+      "rel8ns": {
+        "ancestor": [
+          "sync_sagamsg^gib"
+        ]
+      }
+    }
+  ],
+  "identities": []
+} (I: e5a9436fb66b0df3183bd6d81be2ca26)
+[SyncSagaCoordinator][executeLocalCommit][receiver] allPayloadAddrsDomainTransferred: constant_c1^2B4B05537B40B9B5FC501E58EE9256B6F33259BA629A4633113B8104C1B5B08C (I: a1950eb3ca95bdc9ec18a4b8823e9826)
+[SyncSagaCoordinator][executeLocalCommit][receiver] 1 changes detected (I: fa30d18e83a87ee9e8487fbb5d632b26)
+[SyncSagaCoordinator][executeLocalCommit] put all into localSpace (witness space InnerSpace_V1 source source_uuid undefined undefined) starting... (I: d5e0d9870e380b61e80c729660058826)
+[putInSpace] [InnerSpace_V1][putImpl] already had addr(s): constant_c1^2B4B05537B40B9B5FC501E58EE9256B6F33259BA629A4633113B8104C1B5B08C
+[putInSpace] (W: 7120c8267c2aaf8cad5d2f3850666826)
+[SyncSagaCoordinator][executeLocalCommit] put all into localSpace (witness space InnerSpace_V1 source source_uuid undefined undefined) complete. (I: d5e0d9870e380b61e80c729660058826)
+[SyncSagaCoordinator][executeLocalCommit] register mapWithoutTjps starting... (I: 2b84d8f8dda85adde88696d8419bf726)
+[SyncSagaCoordinator][executeLocalCommit] registering constant_c1^2B4B05537B40B9B5FC501E58EE9256B6F33259BA629A4633113B8104C1B5B08C (I: 4647b4f42d27cffe0fbfce8846755826)
+[SyncSagaCoordinator][executeLocalCommit] mapWithoutTjps complete. (I: 2b84d8f8dda85adde88696d8419bf726)
+[SyncSagaCoordinator][executeLocalCommit] register mapWithTjp_NoDna starting... (I: 96e648e4db382499b8bfaa1b37c24826)
+[SyncSagaCoordinator][executeLocalCommit] register mapWithTjp_NoDna complete. (I: 96e648e4db382499b8bfaa1b37c24826)
+[SyncSagaCoordinator][executeLocalCommit] register mapWithTjp_YesDna starting... (I: d54a820e9442dee4681f6228a6795926)
+[SyncSagaCoordinator][executeLocalCommit] register mapWithTjp_YesDna complete. (I: d54a820e9442dee4681f6228a6795926)
+[SyncSagaCoordinator][executeLocalCommit] complete.
+[SyncSagaCoordinator][handleCommitFrame] NAG ERROR (NOT THROWN): implement cleanup logic, including add a cleanup method to the peer (E: 3a9a24befb98a981a88fbdbf52920e26)
+[SyncSagaCoordinator][handleCommitFrame] Peer committed. Finalizing saga locally. Saga Complete.
+[SyncSagaCoordinator][handleCommitFrame] complete.
+[SyncSagaCoordinator][handleResponseSagaContext] nextFrameInfo: {
+  "sagaComplete": true
+} (I: a8ad281ca8e89385686d18327a105726)
+[SyncSagaCoordinator][handleResponseSagaContext] complete.
+[SyncSagaCoordinator][executeSagaLoop] Handler returned null (Saga End). (I: 123bf9e7dca8886de72553a8d4f29e26)