Add unit tests for safeStringify circular, BigInt, and truncation handling

[mikewheeleer]

Test the safeStringify serialiser and safeFormatTimestamp fallbacks

Description

src/lib/format.ts exposes safeStringify (used by the event log to render arbitrary payloads without throwing — handling circular refs as [Circular], BigInt as a marker, functions/symbols/undefined, and truncating past EVENT_PAYLOAD_MAX_CHARS) and safeFormatTimestamp (which coerces malformed timestamps to a placeholder). The formatStroops/formatRequests paths have tests, but these two render-safety helpers do not. This issue covers them.

Requirements and context

• Repository scope: Agentpay-Org/Agentpay-frontend only.
• For safeStringify: assert circular objects produce [Circular], BigInt produces [BigInt:…], top-level undefined/function/symbol return the typeof sentinel, and an over-long string is truncated with EVENT_PAYLOAD_TRUNCATED_MARKER.
• Assert a custom maxChars is respected and small payloads are returned untruncated.
• For safeFormatTimestamp: assert valid numeric/string timestamps return ISO, and null/undefined/non-finite/NaN inputs return the fallback dash.

Suggested execution

• Fork the repo and create a branch
• git checkout -b test/testing-safestringify-timestamp
• Implement changes
  • Write comprehensive tests in: extend src/lib/__tests__/format.test.ts.
  • Write code in: no source change expected (file a follow-up if a bug is found).
  • Add documentation: none beyond test descriptions.
  • Validate the function never throws for any input shape.
• Test and commit

Test and commit

• Run npm run lint, npm run typecheck, and npm test.
• Cover edge cases: nested circular, a payload exactly at the limit, BigInt inside an array, and a "not-a-date" timestamp string.
• Include the npm test output and coverage for format.ts.

Example commit message

test(lib): cover safeStringify circular/BigInt/truncation and safeFormatTimestamp

Guidelines

• Minimum 95 percent test coverage for the impacted functions.
• Clear, reviewer-focused documentation.
• Timeframe: 96 hours.

Community & contribution rewards

• 💬 Join the AgentPay community on Discord for questions, reviews, and faster merges: https://discord.gg/eXvRKkgcv
• ⭐ This is a GrantFox OSS / Official Campaign task and may be rewarded. When your PR is merged you'll be prompted to rate the project — if this issue and the maintainers helped you ship, we'd be grateful for a 5-star rating. Clear questions in Discord and tidy, well-tested PRs are the fastest path to a merge and a reward.

[gloskull]

Hello, I have 4 years of experience delivering solutions for projects like this, covering backend, frontend, and smart contract development. After carefully reviewing your requirements, I have a clear understanding of the task and am confident in my ability to deliver a clean, efficient, and thoroughly tested solution on time. I prioritize code quality, maintainability, and industry best practices throughout the development process.
My PR will be submitted in under 10hours.

[GBOYEE]

looked at src/lib/format.ts — the two functions are solid. safeStringify uses a WeakSet for circular detection and handles all the edge cases (bigint, function, symbol, undefined top-level). safeFormatTimestamp is straightforward — coerces to number, checks finite, falls back to em-dash.

tests i'll write:

safeStringify:

• circular ref → [Circular] in output
• BigInt → [BigInt:...]
• top-level undefined → [undefined]
• function/symbol → [Function] / [Symbol]
• string within maxChars → returned as-is
• string over maxChars → truncated with \n…(truncated)
• custom maxChars respected
• nested circular (object inside array) → both detected

safeFormatTimestamp:

• valid number → ISO string
• valid numeric string → ISO string
• null/undefined → em-dash
• NaN/Infinity → em-dash
• "not-a-date" → em-dash (NaN from Number())

will extend src/lib/__tests__/format.test.ts since the file already exists for formatStroops/formatRequests. no source changes expected — the code is clean.

one thing — the BigInt replacer returns [BigInt:${v.toString()}] which could theoretically be huge if someone passes a massive BigInt. not a bug per se, but worth a test case to confirm it doesn't throw. anyway, standard cases first.