Numbers That Survive Rollback

Numbers That Survive Rollback

Your extension writes an event log that external systems consume: every telemetry probe, webhook and integration job calls one allocator, takes an event id, and ships it downstream, where consumers deduplicate on that id. This is the mirror image of gapless invoice numbering — here a gap costs nothing, but a reused id silently merges two different events on every consumer. An id, once handed out, must never appear again: not after a crash, and above all not after a rollback. And because every process in the system calls this allocator, it has to stay cheap no matter how big the log grows.

The starter ships the finished log table. Do not rename it or its fields — the grading tests bind to every name below character for character.

The objects you get

• Table "Event Log Entry" — primary key "Entry Id" (BigInteger); fields "Source Code" (Code[20]) and Description (Text[100]).

Requirements

Implement the procedure in the codeunit "Event Id Allocator":

procedure LogEvent(SourceCode: Code[20]; Description: Text[100]): BigInteger

Rules:

1. Allocation — each call draws a fresh event id and returns it. Every id is strictly greater than every id any earlier call has returned, whether that call succeeded or not, and no id is ever negative (the tests park bookkeeping entries of their own at negative ids).
2. The entry — each call writes exactly one "Event Log Entry": "Entry Id" is the returned id, "Source Code" and Description are copied verbatim from the parameters.