refactor: delegate ChittyID minting to ChittyMint service#6
Conversation
- ChittyID now calls ChittyMint (mint.chitty.cc) for ID generation - Removed local minting logic (drand, trust resolution, etc.) - Added ChittyIDClient library for service consumers - Added TrustClient for trust level resolution - Fixed drand-beacon.js signed integer overflow (>>> 0) ChittyMint is now the single source of truth for minting. ChittyID serves as the API layer for validation and spec. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ❌ Deployment failed View logs |
chittyid | f4f44a0 | Jan 23 2026, 01:31 AM |
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. 📝 WalkthroughWalkthroughAdds a new ChittyID JavaScript client, introduces a TrustClient service for multi-source trust resolution, ensures unsigned 32-bit conversion in drand-beacon, and refactors worker logic to delegate ChittyID minting to an external ChittyMint service with fallback handling. Changes
Sequence DiagramsequenceDiagram
participant Client
participant Worker
participant ChittyMint as ChittyMint API
participant KV as Pending KV
Client->>Worker: request mint (with Authorization, CF-IPCountry)
activate Worker
Worker->>ChittyMint: POST /api/mint (forward headers + body)
alt ChittyMint success
ChittyMint-->>Worker: mint response (chittyId + metadata)
Worker-->>Client: return minted ChittyID
else ChittyMint failure
ChittyMint-->>Worker: error
Worker->>KV: store pending mint request
Worker-->>Client: return fallback error-id
end
deactivate Worker
sequenceDiagram
participant Caller
participant TrustClient
participant ChittyTrust as ChittyTrust API
participant ChittyScore as ChittyScore API
Caller->>TrustClient: resolveTrustLevel(context)
activate TrustClient
TrustClient->>TrustClient: isSystemService(authToken)?
alt System service
TrustClient-->>Caller: TrustResolution (system)
else Not system
TrustClient->>ChittyTrust: getPolicyTrustLevel(authToken)
alt Policy available
ChittyTrust-->>TrustClient: policy trust (L0-L4)
TrustClient-->>Caller: TrustResolution (policy)
else Policy unavailable
TrustClient->>ChittyScore: getScoreTrustLevel(chittyId)
ChittyScore-->>TrustClient: score + dimensions (or null)
TrustClient-->>Caller: TrustResolution (score/default)
end
end
deactivate TrustClient
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In `@worker.js`:
- Around line 39-40: Replace the hardcoded CHITTYMINT_URL constant with a value
read from environment (e.g., process.env.CHITTYMINT_URL) and provide the
existing 'https://mint.chitty.cc' as the fallback; update the constant
declaration CHITTYMINT_URL accordingly so any code that uses CHITTYMINT_URL will
pick up the env override when present.
- Around line 312-315: The /api/get-chittyid branch currently calls
handleDirectChittyIdGeneration directly; change it to run through the existing
pipeline by invoking createRequestInterceptor(...) to perform security
interception and then createPipelineEnforcer(...) (which applies pipeline
enforcement, circuit breaking and AI routing) so that the intercepted request is
forwarded into the pipeline and ultimately calls handleDirectChittyIdGeneration;
locate the GET branch for "/api/get-chittyid" and replace the direct return with
a pipeline-enforced invocation using the imported createRequestInterceptor and
createPipelineEnforcer functions, ensuring the final handler passed into the
enforcer is handleDirectChittyIdGeneration.
- Around line 64-76: The ChittyMint fetch lacks circuit-breaker and timeout
protection; wrap the outbound call using the imported PipelineIntegrityBreaker
and add an AbortController timeout so slow/failed ChittyMint calls are
short-circuited. Specifically, create an AbortController, start a timer (e.g.,
configurable ms) to call controller.abort(), pass controller.signal into the
fetch that uses CHITTYMINT_URL and mintRequest (and still forward authHeader and
request.cf), and invoke the breaker (PipelineIntegrityBreaker.fire or its API
used elsewhere) to execute the fetch within the breaker; ensure you clear the
timeout on success, catch AbortError and breaker rejections to log via the
existing logger and return/throw a controlled error path instead of hanging.
🧹 Nitpick comments (7)
src/services/trust-client.js (3)
92-127: Add timeout and validate parsed trust level.
- The
fetchcall has no timeout, risking indefinite blocking if ChittyTrust is slow.parseInt(data.data.trustLevel.replace('L', ''))returnsNaNif the format is unexpected.Proposed fix
async getPolicyTrustLevel(authToken) { try { - const response = await fetch(`${this.trustUrl}/api/v1/policies/validate`, { + const controller = new AbortController(); + const timeoutId = setTimeout(() => controller.abort(), 5000); + + const response = await fetch(`${this.trustUrl}/api/v1/policies/validate`, { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${authToken}` }, body: JSON.stringify({ action: 'resolve_trust_level' - }) + }), + signal: controller.signal }); + clearTimeout(timeoutId); if (!response.ok) { return null; } const data = await response.json(); if (data.success && data.data?.trustLevel) { // Convert L0-L4 to 0-4 const levelNum = parseInt(data.data.trustLevel.replace('L', '')); + if (isNaN(levelNum) || levelNum < 0 || levelNum > 5) { + console.warn('Invalid trust level format:', data.data.trustLevel); + return null; + } return { level: levelNum,
140-172: Add timeout to ChittyScore fetch.Same concern as
getPolicyTrustLevel—the fetch has no timeout. Consider usingAbortControllerwith a reasonable timeout (e.g., 5 seconds) to prevent indefinite blocking.
33-77: Consider adding audit trail for trust resolution.Per coding guidelines, services should maintain a complete audit trail for ID generation and reconciliation operations. Trust resolution is a key step in the minting flow, but
resolveTrustLeveldoesn't log/store the resolution decision for later audit.Consider storing or emitting an audit record with the resolved level, source, and request context (similar to
storeBeaconAuditindrand-beacon.js).src/client/index.js (4)
66-70:process.envusage limits browser compatibility.
process.envis Node.js-specific and undefined in browsers. If this client is intended for universal (browser + Node) use, consider alternative patterns like requiring explicit configuration or documenting Node.js-only usage.Proposed fix for universal compatibility
constructor(options = {}) { - this.serviceUrl = options.serviceUrl || process.env.CHITTYID_SERVICE_URL || DEFAULT_SERVICE_URL; - this.token = options.token || process.env.CHITTY_SERVICE_TOKEN; - this.apiKey = options.apiKey || process.env.CHITTY_API_KEY; + this.serviceUrl = options.serviceUrl || + (typeof process !== 'undefined' && process.env?.CHITTYID_SERVICE_URL) || + DEFAULT_SERVICE_URL; + this.token = options.token || + (typeof process !== 'undefined' && process.env?.CHITTY_SERVICE_TOKEN); + this.apiKey = options.apiKey || + (typeof process !== 'undefined' && process.env?.CHITTY_API_KEY); }
175-181: Inconsistent error handling inhealth().Unlike
mint(),validate(), andgetSpec(), thehealth()method doesn't checkresponse.okbefore parsing JSON. If the service returns a non-2xx status, the caller won't know unless they inspect the response body.Proposed fix
async health() { const response = await fetch(`${this.serviceUrl}/api/health`, { method: 'GET' }); + if (!response.ok) { + return { status: 'unhealthy', statusCode: response.status }; + } + return response.json(); }
104-123: Consider adding request timeout.The
mint()method has no timeout protection. A slow or unresponsive server could cause the promise to hang indefinitely. Consider usingAbortControllerwith a configurable timeout.
189-212: Consider adding Mod-97 checksum validation toparse().The static
parse()method doesn't verify the checksum, allowing malformed or tampered IDs to be parsed without error. While full validation is available viavalidate(), adding a basic checksum check here would provide early client-side detection of invalid IDs.
| try { | ||
| const sequentialKey = `seq_${region}_${jurisdiction}_${entityType}`; | ||
| const sequential = await getNextSequential(env, sequentialKey); | ||
| const yearMonth = getCurrentYearMonth(); | ||
| // Call ChittyMint for actual ID generation | ||
| const mintResponse = await fetch(`${CHITTYMINT_URL}/api/mint`, { | ||
| method: 'POST', | ||
| headers: { | ||
| 'Content-Type': 'application/json', | ||
| ...(authHeader ? { 'Authorization': authHeader } : {}), | ||
| // Forward CF geolocation for region/jurisdiction auto-detection | ||
| ...(request?.cf?.country ? { 'CF-IPCountry': request.cf.country } : {}) | ||
| }, | ||
| body: JSON.stringify(mintRequest) | ||
| }); | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's check the worker.js file structure and locate the relevant sections
head -n 100 worker.js | cat -nRepository: chittyfoundation/chittyid
Length of output: 4496
🏁 Script executed:
# Search for PipelineIntegrityBreaker import and usage
rg -n "PipelineIntegrityBreaker" worker.js -A 3Repository: chittyfoundation/chittyid
Length of output: 290
🏁 Script executed:
# Check the handleDirectChittyIdGeneration function around lines 43-100
sed -n '40,100p' worker.js | cat -nRepository: chittyfoundation/chittyid
Length of output: 2658
🏁 Script executed:
# Search for circuit breaker usage patterns elsewhere in the codebase
rg -n "circuit.*break" --type js -iRepository: chittyfoundation/chittyid
Length of output: 5702
🏁 Script executed:
# Look for timeout patterns in fetch calls
rg -n "AbortController|fetch.*signal" --type jsRepository: chittyfoundation/chittyid
Length of output: 475
Add circuit breaking and timeout protection to ChittyMint fetch call.
Per coding guidelines and the mandatory pipeline enforcement system, all ChittyID generation code must include circuit breaking. The fetch to ChittyMint (line 66) lacks both circuit breaker protection and timeout. Without these safeguards, slow or failing ChittyMint responses will cause cascading failures. The PipelineIntegrityBreaker is imported (line 9) but unused; other handlers in the codebase consistently apply it.
Proposed fix with timeout and circuit breaker
try {
+ const controller = new AbortController();
+ const timeoutId = setTimeout(() => controller.abort(), 10000); // 10s timeout
+ const circuitBreaker = new PipelineIntegrityBreaker(env);
+
+ const circuitCheck = await circuitBreaker.checkCircuit('mint', 'generation');
+ if (!circuitCheck.allowed) {
+ return new Response(JSON.stringify({
+ success: false,
+ error: 'CIRCUIT_BREAKER_OPEN',
+ message: 'ChittyMint service temporarily unavailable',
+ timestamp: new Date().toISOString()
+ }), {
+ status: 503,
+ headers: { 'Content-Type': 'application/json', 'Access-Control-Allow-Origin': '*' }
+ });
+ }
+
// Call ChittyMint for actual ID generation
const mintResponse = await fetch(`${CHITTYMINT_URL}/api/mint`, {
method: 'POST',
headers: {
'Content-Type': 'application/json',
...(authHeader ? { 'Authorization': authHeader } : {}),
// Forward CF geolocation for region/jurisdiction auto-detection
...(request?.cf?.country ? { 'CF-IPCountry': request.cf.country } : {})
},
- body: JSON.stringify(mintRequest)
+ body: JSON.stringify(mintRequest),
+ signal: controller.signal
});
+ clearTimeout(timeoutId);
+ await circuitBreaker.recordSuccess('mint', 'generation');📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| try { | |
| const sequentialKey = `seq_${region}_${jurisdiction}_${entityType}`; | |
| const sequential = await getNextSequential(env, sequentialKey); | |
| const yearMonth = getCurrentYearMonth(); | |
| // Call ChittyMint for actual ID generation | |
| const mintResponse = await fetch(`${CHITTYMINT_URL}/api/mint`, { | |
| method: 'POST', | |
| headers: { | |
| 'Content-Type': 'application/json', | |
| ...(authHeader ? { 'Authorization': authHeader } : {}), | |
| // Forward CF geolocation for region/jurisdiction auto-detection | |
| ...(request?.cf?.country ? { 'CF-IPCountry': request.cf.country } : {}) | |
| }, | |
| body: JSON.stringify(mintRequest) | |
| }); | |
| try { | |
| const controller = new AbortController(); | |
| const timeoutId = setTimeout(() => controller.abort(), 10000); // 10s timeout | |
| const circuitBreaker = new PipelineIntegrityBreaker(env); | |
| const circuitCheck = await circuitBreaker.checkCircuit('mint', 'generation'); | |
| if (!circuitCheck.allowed) { | |
| return new Response(JSON.stringify({ | |
| success: false, | |
| error: 'CIRCUIT_BREAKER_OPEN', | |
| message: 'ChittyMint service temporarily unavailable', | |
| timestamp: new Date().toISOString() | |
| }), { | |
| status: 503, | |
| headers: { 'Content-Type': 'application/json', 'Access-Control-Allow-Origin': '*' } | |
| }); | |
| } | |
| // Call ChittyMint for actual ID generation | |
| const mintResponse = await fetch(`${CHITTYMINT_URL}/api/mint`, { | |
| method: 'POST', | |
| headers: { | |
| 'Content-Type': 'application/json', | |
| ...(authHeader ? { 'Authorization': authHeader } : {}), | |
| // Forward CF geolocation for region/jurisdiction auto-detection | |
| ...(request?.cf?.country ? { 'CF-IPCountry': request.cf.country } : {}) | |
| }, | |
| body: JSON.stringify(mintRequest), | |
| signal: controller.signal | |
| }); | |
| clearTimeout(timeoutId); | |
| await circuitBreaker.recordSuccess('mint', 'generation'); |
🤖 Prompt for AI Agents
In `@worker.js` around lines 64 - 76, The ChittyMint fetch lacks circuit-breaker
and timeout protection; wrap the outbound call using the imported
PipelineIntegrityBreaker and add an AbortController timeout so slow/failed
ChittyMint calls are short-circuited. Specifically, create an AbortController,
start a timer (e.g., configurable ms) to call controller.abort(), pass
controller.signal into the fetch that uses CHITTYMINT_URL and mintRequest (and
still forward authHeader and request.cf), and invoke the breaker
(PipelineIntegrityBreaker.fire or its API used elsewhere) to execute the fetch
within the breaker; ensure you clear the timeout on success, catch AbortError
and breaker rejections to log via the existing logger and return/throw a
controlled error path instead of hanging.
| // Direct API handlers (bypassing Pages Functions import issues) | ||
| if (url.pathname === "/api/get-chittyid" && request.method === "GET") { | ||
| return await handleDirectChittyIdGeneration(url, env); | ||
| return await handleDirectChittyIdGeneration(url, env, request); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# First, locate and examine worker.js
find . -name "worker.js" -type f | head -5Repository: chittyfoundation/chittyid
Length of output: 96
🏁 Script executed:
#!/bin/bash
# Check the root worker.js around the mentioned lines and see imports
echo "=== Lines 1-30 of ./worker.js (imports and start) ==="
head -30 ./worker.js
echo -e "\n=== Lines 305-320 of ./worker.js (the route in question) ==="
sed -n '305,320p' ./worker.js
echo -e "\n=== Check file length ==="
wc -l ./worker.jsRepository: chittyfoundation/chittyid
Length of output: 2193
🏁 Script executed:
#!/bin/bash
# Find handleDirectChittyIdGeneration implementation
echo "=== Searching for handleDirectChittyIdGeneration definition ==="
rg -n "function handleDirectChittyIdGeneration|const handleDirectChittyIdGeneration|handleDirectChittyIdGeneration\s*=" ./worker.js -A 15
echo -e "\n=== Check all uses of createPipelineEnforcer in worker.js ==="
rg -n "createPipelineEnforcer" ./worker.js -B 2 -A 5
echo -e "\n=== Check all uses of createRequestInterceptor in worker.js ==="
rg -n "createRequestInterceptor" ./worker.js -B 2 -A 5Repository: chittyfoundation/chittyid
Length of output: 1795
🏁 Script executed:
#!/bin/bash
# Get full handleDirectChittyIdGeneration function
echo "=== Full handleDirectChittyIdGeneration implementation ==="
sed -n '43,100p' ./worker.jsRepository: chittyfoundation/chittyid
Length of output: 2176
🏁 Script executed:
#!/bin/bash
# Check CHITTYMINT_URL definition
echo "=== Search for CHITTYMINT_URL definition ==="
rg -n "CHITTYMINT_URL" ./worker.js -B 2 -A 2
# Check if any other routes use pipeline enforcement
echo -e "\n=== Check if any routes apply pipeline enforcer ==="
rg -n "createPipelineEnforcer|pipelineEnforcer|enforcer\(" ./worker.js
# See all route handlers in this file
echo -e "\n=== Check other route patterns ==="
rg -n "if.*pathname.*===" ./worker.js | head -20Repository: chittyfoundation/chittyid
Length of output: 1184
🏁 Script executed:
#!/bin/bash
# Final check: see if pipeline enforcer is used anywhere in the codebase at all
echo "=== Check if createPipelineEnforcer is actually used anywhere in codebase ==="
rg -l "createPipelineEnforcer\(" --type=js | head -10
echo -e "\n=== Sample usage if found ==="
rg "createPipelineEnforcer\(" --type=js -A 3 | head -30Repository: chittyfoundation/chittyid
Length of output: 2151
Apply mandatory pipeline enforcement to /api/get-chittyid route.
The /api/get-chittyid route bypasses the mandatory pipeline: Security Interception → Pipeline Enforcement → Circuit Breaking → AI Routing. The route calls handleDirectChittyIdGeneration directly without wrapping it with createPipelineEnforcer or createRequestInterceptor (imported on lines 7-8 but unused). While the function correctly delegates ID generation to the external ChittyMint service, it must pass through the required pipeline enforcement layers first.
🤖 Prompt for AI Agents
In `@worker.js` around lines 312 - 315, The /api/get-chittyid branch currently
calls handleDirectChittyIdGeneration directly; change it to run through the
existing pipeline by invoking createRequestInterceptor(...) to perform security
interception and then createPipelineEnforcer(...) (which applies pipeline
enforcement, circuit breaking and AI routing) so that the intercepted request is
forwarded into the pipeline and ultimately calls handleDirectChittyIdGeneration;
locate the GET branch for "/api/get-chittyid" and replace the direct return with
a pipeline-enforced invocation using the imported createRequestInterceptor and
createPipelineEnforcer functions, ensuring the final handler passed into the
enforcer is handleDirectChittyIdGeneration.
Co-authored-by: chitcommit <208086304+chitcommit@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
This pull request refactors the ChittyID service to delegate ID minting to an external ChittyMint service (mint.chitty.cc), adds trust level resolution infrastructure, and fixes a signed integer overflow bug in drand beacon hash calculation.
Changes:
- Delegates ChittyID generation from id.chitty.cc to mint.chitty.cc external service
- Adds TrustClient service for trust level resolution with ChittyTrust and ChittyScore integration
- Adds JavaScript client library for ChittyID operations
- Fixes drand-beacon.js signed integer overflow using unsigned right shift operator
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 9 comments.
| File | Description |
|---|---|
| worker.js | Refactored to delegate minting to ChittyMint service, updated validation regex for yearMonth field from 2-3 digits to 4 digits (YYMM format) |
| src/services/trust-client.js | New trust level resolution service integrating ChittyTrust and ChittyScore APIs (not yet integrated into codebase) |
| src/services/drand-beacon.js | Fixed hash calculation to prevent negative values using unsigned right shift operator (>>> 0) |
| src/client/index.js | New JavaScript client library for ChittyID minting and validation operations |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| * | ||
| * const client = new ChittyIDClient({ token: 'your-service-token' }); | ||
| * const result = await client.mint('person', { jurisdiction: 'USA' }); | ||
| * console.log(result.chittyId); // 03-1-USA-1234-P-2601-3-42 |
There was a problem hiding this comment.
The example ChittyID format in the comment shows "03-1-USA-1234-P-2601-3-42" which has a 4-digit yearMonth field "2601" (likely meant to be YYMM format for January 2026). However, the old format used by the codebase was 3 digits for months 1-9, so this example is inconsistent with existing IDs in the system. If ChittyMint now uses 4-digit YYMM consistently, this is fine, but it should be verified and documented. Consider updating the example to clarify the new format or ensuring it matches the actual format returned by ChittyMint.
| * console.log(result.chittyId); // 03-1-USA-1234-P-2601-3-42 | |
| * console.log(result.chittyId); // e.g. 03-1-USA-1234-P-261-3-42 (yearMonth is 3-digit YMM, so 261 = Jan 2026) |
| year: yearMonth.substring(0, 2), | ||
| month: yearMonth.substring(2, 4), |
There was a problem hiding this comment.
The parse method assumes yearMonth is always 4 digits (lines 207-208 extract year and month as 2 digits each). However, the old format used 3 digits for months 1-9, which would cause incorrect parsing. For example, "251" (Jan 2025) would be parsed as year="25" and month="1" (single digit), while the code expects 2-digit months. This will cause issues when parsing older ChittyIDs. Consider handling both formats or documenting that this only works with the new 4-digit YYMM format.
| } catch (error) { | ||
| return new Response(JSON.stringify({ | ||
| success: false, | ||
| error: 'GENERATION_FAILED', | ||
| message: error.message, | ||
| error: 'MINT_SERVICE_ERROR', | ||
| message: `Failed to reach ChittyMint: ${error.message}`, | ||
| fallback: 'ChittyMint service unavailable', | ||
| timestamp: new Date().toISOString() | ||
| }), { | ||
| status: 500, | ||
| status: 503, | ||
| headers: { 'Content-Type': 'application/json', 'Access-Control-Allow-Origin': '*' } | ||
| }); | ||
| } |
There was a problem hiding this comment.
The error handler catches all errors when calling ChittyMint, including JSON parsing errors on line 77. If the response from ChittyMint is not valid JSON, the error will be caught and a generic 503 error will be returned. However, if mintResponse.json() fails, the actual HTTP status from ChittyMint is lost. Consider handling JSON parsing separately or checking response.ok before attempting to parse the JSON to preserve the actual error status from ChittyMint.
| const authHeader = request?.headers?.get('Authorization'); | ||
|
|
||
| // Build request body for ChittyMint | ||
| const mintRequest = { | ||
| entityType: entityTypeParam | ||
| }; | ||
|
|
||
| // Add optional parameters if provided | ||
| const regionParam = url.searchParams.get('region'); | ||
| if (regionParam) mintRequest.region = regionParam; | ||
|
|
||
| const jurisdictionParam = url.searchParams.get('jurisdiction'); | ||
| if (jurisdictionParam) mintRequest.jurisdiction = jurisdictionParam; | ||
|
|
||
| const trustParam = url.searchParams.get('trust'); | ||
| if (trustParam) mintRequest.trust = parseInt(trustParam); | ||
|
|
||
| try { | ||
| const sequentialKey = `seq_${region}_${jurisdiction}_${entityType}`; | ||
| const sequential = await getNextSequential(env, sequentialKey); | ||
| const yearMonth = getCurrentYearMonth(); | ||
| // Call ChittyMint for actual ID generation | ||
| const mintResponse = await fetch(`${CHITTYMINT_URL}/api/mint`, { | ||
| method: 'POST', | ||
| headers: { | ||
| 'Content-Type': 'application/json', | ||
| ...(authHeader ? { 'Authorization': authHeader } : {}), |
There was a problem hiding this comment.
The Authorization header is extracted from the request and passed through to ChittyMint. However, there's no validation or sanitization of this header. If this is a Bearer token meant for id.chitty.cc, it's being forwarded to mint.chitty.cc which may not expect it or may interpret it differently. Consider documenting the expected authentication flow between id.chitty.cc and mint.chitty.cc, or using a service-to-service token instead of forwarding user tokens.
| this.serviceUrl = options.serviceUrl || process.env.CHITTYID_SERVICE_URL || DEFAULT_SERVICE_URL; | ||
| this.token = options.token || process.env.CHITTY_SERVICE_TOKEN; | ||
| this.apiKey = options.apiKey || process.env.CHITTY_API_KEY; |
There was a problem hiding this comment.
The client library references process.env on line 67, which is not available in browser environments. This will cause a ReferenceError if this code runs in a browser. Consider wrapping the process.env access in a try-catch or checking if process is defined (e.g., typeof process !== 'undefined' && process.env) to make this library browser-compatible, or document that it's server-side only.
| this.serviceUrl = options.serviceUrl || process.env.CHITTYID_SERVICE_URL || DEFAULT_SERVICE_URL; | |
| this.token = options.token || process.env.CHITTY_SERVICE_TOKEN; | |
| this.apiKey = options.apiKey || process.env.CHITTY_API_KEY; | |
| const env = (typeof process !== 'undefined' && process.env) ? process.env : {}; | |
| this.serviceUrl = options.serviceUrl || env.CHITTYID_SERVICE_URL || DEFAULT_SERVICE_URL; | |
| this.token = options.token || env.CHITTY_SERVICE_TOKEN; | |
| this.apiKey = options.apiKey || env.CHITTY_API_KEY; |
| if (jurisdictionParam) mintRequest.jurisdiction = jurisdictionParam; | ||
|
|
||
| const trustParam = url.searchParams.get('trust'); | ||
| if (trustParam) mintRequest.trust = parseInt(trustParam); |
There was a problem hiding this comment.
The trust parameter from the query string is parsed as an integer but not validated before being sent to ChittyMint. If a user provides an invalid value (negative, > 5, or non-numeric), it will be sent to ChittyMint as-is. Consider validating that the trust level is between 0-5 before forwarding to ChittyMint, or let ChittyMint handle the validation but ensure error responses are properly communicated back to the client.
| if (trustParam) mintRequest.trust = parseInt(trustParam); | |
| if (trustParam !== null) { | |
| const trustValue = Number(trustParam); | |
| if (!Number.isInteger(trustValue) || trustValue < 0 || trustValue > 5) { | |
| return new Response(JSON.stringify({ | |
| success: false, | |
| error: 'INVALID_TRUST_LEVEL', | |
| message: 'The "trust" parameter must be an integer between 0 and 5.', | |
| providedValue: trustParam, | |
| timestamp: new Date().toISOString() | |
| }), { | |
| status: 400, | |
| headers: { 'Content-Type': 'application/json', 'Access-Control-Allow-Origin': '*' } | |
| }); | |
| } | |
| mintRequest.trust = trustValue; | |
| } |
| if (!/^\d{4}$/.test(sequential)) return { valid: false, error: 'Sequential must be 4 digits' }; | ||
| if (!/^[PLTEA]$/.test(entityType)) return { valid: false, error: 'Entity type must be P, L, T, E, or A' }; | ||
| if (!/^\d{2,3}$/.test(yearMonth)) return { valid: false, error: 'Year-Month must be 2-3 digits' }; | ||
| if (!/^\d{4}$/.test(yearMonth)) return { valid: false, error: 'Year-Month must be 4 digits (YYMM)' }; |
There was a problem hiding this comment.
The validation regex change from \d{2,3} to \d{4} for yearMonth is inconsistent with how the old code generated this field. The old getCurrentYearMonth() function (visible in other files like api-id/index.ts:63) returns year + month.slice(1), which produces 3 digits for months 1-9 (e.g., "251" for Jan 2025) and 4 digits for months 10-12 (e.g., "2512" for Dec 2025). This validation will reject IDs minted during months 1-9 until ChittyMint is confirmed to use the new YYMM 4-digit format. The validation in src/workers/chittyid-realtime.ts:344 still uses \d{2,3} pattern, creating an inconsistency. Either revert this to \d{2,3} or ensure ChittyMint consistently uses 4-digit YYMM format and update all validators across the codebase consistently.
| if (!/^\d{4}$/.test(yearMonth)) return { valid: false, error: 'Year-Month must be 4 digits (YYMM)' }; | |
| if (!/^\d{2,3}$/.test(yearMonth)) return { valid: false, error: 'Year-Month must be 2-3 digits' }; |
| /** | ||
| * ChittyTrust Client for Trust Level Resolution | ||
| * | ||
| * Integrates with ChittyTrust (trust.chitty.cc) for certificate policy trust levels | ||
| * and ChittyScore (score.chitty.cc) for 6D behavioral trust scoring. | ||
| * | ||
| * Trust Level Mapping: | ||
| * L0 (0) - Anonymous: No identity verification | ||
| * L1 (1) - Basic: Email verified | ||
| * L2 (2) - Enhanced: Identity document verified | ||
| * L3 (3) - Professional: Organization verified | ||
| * L4 (4) - Institutional: Full compliance audit | ||
| * L5 (5) - Official: Reserved for ChittyOS system services | ||
| */ | ||
|
|
||
| export class TrustClient { | ||
| constructor(env) { | ||
| this.env = env; | ||
| this.trustUrl = env?.CHITTYTRUST_URL || 'https://trust.chitty.cc'; | ||
| this.scoreUrl = env?.CHITTYSCORE_URL || 'https://score.chitty.cc'; | ||
| this.serviceToken = env?.CHITTY_SERVICE_TOKEN; | ||
| } | ||
|
|
||
| /** | ||
| * Resolve trust level for a ChittyID minting request | ||
| * | ||
| * @param {Object} context - Request context | ||
| * @param {string} context.authToken - Bearer token from request (if authenticated) | ||
| * @param {string} context.chittyId - Existing ChittyID of requestor (if known) | ||
| * @param {string} context.entityType - Type being minted (P/L/T/E/A) | ||
| * @returns {Promise<TrustResolution>} | ||
| */ | ||
| async resolveTrustLevel(context) { | ||
| const { authToken, chittyId, entityType } = context; | ||
|
|
||
| // L5 (Official) - Only for internal system services | ||
| if (this.isSystemService(authToken)) { | ||
| return { | ||
| level: 5, | ||
| source: 'system', | ||
| reason: 'Authenticated system service', | ||
| verified: true | ||
| }; | ||
| } | ||
|
|
||
| // Try ChittyTrust policy-based trust level | ||
| if (authToken) { | ||
| try { | ||
| const policyTrust = await this.getPolicyTrustLevel(authToken); | ||
| if (policyTrust) { | ||
| return policyTrust; | ||
| } | ||
| } catch (error) { | ||
| console.warn('ChittyTrust lookup failed:', error.message); | ||
| } | ||
| } | ||
|
|
||
| // Try ChittyScore behavioral trust (when available) | ||
| if (chittyId) { | ||
| try { | ||
| const scoreTrust = await this.getScoreTrustLevel(chittyId); | ||
| if (scoreTrust) { | ||
| return scoreTrust; | ||
| } | ||
| } catch (error) { | ||
| console.warn('ChittyScore lookup failed:', error.message); | ||
| } | ||
| } | ||
|
|
||
| // Default: L0 for unauthenticated, L1 for authenticated but unverified | ||
| return { | ||
| level: authToken ? 1 : 0, | ||
| source: 'default', | ||
| reason: authToken ? 'Authenticated but no trust record' : 'Unauthenticated request', | ||
| verified: false | ||
| }; | ||
| } | ||
|
|
||
| /** | ||
| * Check if request is from a system service | ||
| */ | ||
| isSystemService(authToken) { | ||
| if (!authToken || !this.serviceToken) return false; | ||
| // System services use service tokens, not user tokens | ||
| return authToken.startsWith('CHITTY_SERVICE_') || | ||
| authToken === this.serviceToken; | ||
| } | ||
|
|
||
| /** | ||
| * Get trust level from ChittyTrust certificate policies | ||
| */ | ||
| async getPolicyTrustLevel(authToken) { | ||
| try { | ||
| const response = await fetch(`${this.trustUrl}/api/v1/policies/validate`, { | ||
| method: 'POST', | ||
| headers: { | ||
| 'Content-Type': 'application/json', | ||
| 'Authorization': `Bearer ${authToken}` | ||
| }, | ||
| body: JSON.stringify({ | ||
| action: 'resolve_trust_level' | ||
| }) | ||
| }); | ||
|
|
||
| if (!response.ok) { | ||
| return null; | ||
| } | ||
|
|
||
| const data = await response.json(); | ||
| if (data.success && data.data?.trustLevel) { | ||
| // Convert L0-L4 to 0-4 | ||
| const levelNum = parseInt(data.data.trustLevel.replace('L', '')); | ||
| return { | ||
| level: levelNum, | ||
| source: 'chittytrust', | ||
| policyOid: data.data.policyOid, | ||
| reason: `Certificate policy ${data.data.policyOid}`, | ||
| verified: true | ||
| }; | ||
| } | ||
|
|
||
| return null; | ||
| } catch (error) { | ||
| console.error('ChittyTrust API error:', error); | ||
| return null; | ||
| } | ||
| } | ||
|
|
||
| /** | ||
| * Get trust level from ChittyScore 6D behavioral scoring | ||
| * | ||
| * ChittyScore dimensions (6D): | ||
| * - Identity verification score | ||
| * - Transaction history score | ||
| * - Governance participation score | ||
| * - Network reputation score | ||
| * - Compliance record score | ||
| * - Time-based trust decay/growth | ||
| */ | ||
| async getScoreTrustLevel(chittyId) { | ||
| try { | ||
| const response = await fetch(`${this.scoreUrl}/api/v1/score/${chittyId}`, { | ||
| method: 'GET', | ||
| headers: { | ||
| 'Content-Type': 'application/json', | ||
| 'X-Service-Token': this.serviceToken || '' | ||
| } | ||
| }); | ||
|
|
||
| if (!response.ok) { | ||
| // ChittyScore not deployed yet - return null to use fallback | ||
| return null; | ||
| } | ||
|
|
||
| const data = await response.json(); | ||
| if (data.success && data.data?.trustLevel !== undefined) { | ||
| return { | ||
| level: data.data.trustLevel, | ||
| source: 'chittyscore', | ||
| score: data.data.compositeScore, | ||
| dimensions: data.data.dimensions, | ||
| reason: `6D composite score: ${data.data.compositeScore}`, | ||
| verified: true | ||
| }; | ||
| } | ||
|
|
||
| return null; | ||
| } catch (error) { | ||
| // ChittyScore not available - this is expected until it's deployed | ||
| return null; | ||
| } | ||
| } | ||
|
|
||
| /** | ||
| * Validate that a requested trust level is allowed | ||
| * | ||
| * @param {number} requestedLevel - Trust level requested by caller | ||
| * @param {TrustResolution} resolved - Resolved trust level | ||
| * @returns {number} - Allowed trust level (min of requested and resolved) | ||
| */ | ||
| validateRequestedLevel(requestedLevel, resolved) { | ||
| // Can't request higher than what you're entitled to | ||
| if (requestedLevel > resolved.level) { | ||
| console.warn(`Trust level ${requestedLevel} requested but only ${resolved.level} allowed`); | ||
| return resolved.level; | ||
| } | ||
| // Can request lower if desired (e.g., anonymous mode) | ||
| return requestedLevel; | ||
| } | ||
| } | ||
|
|
||
| /** | ||
| * @typedef {Object} TrustResolution | ||
| * @property {number} level - Trust level 0-5 | ||
| * @property {string} source - Where trust was resolved from (system/chittytrust/chittyscore/default) | ||
| * @property {string} reason - Human-readable reason | ||
| * @property {boolean} verified - Whether trust was actively verified | ||
| * @property {string} [policyOid] - Certificate policy OID (if from ChittyTrust) | ||
| * @property {number} [score] - Composite score (if from ChittyScore) | ||
| * @property {Object} [dimensions] - 6D score breakdown (if from ChittyScore) | ||
| */ |
There was a problem hiding this comment.
The TrustClient class is introduced in this PR but is not imported or used anywhere in the codebase. It appears to be intended for integration with the ChittyMint service for trust level resolution, but there's no code that actually instantiates or uses this client. This suggests the integration is incomplete. Either integrate TrustClient into the minting flow (possibly in ChittyMint service) or remove it from this PR until it's ready to be used.
| * @param {string} context.entityType - Type being minted (P/L/T/E/A) | ||
| * @returns {Promise<TrustResolution>} | ||
| */ | ||
| async resolveTrustLevel(context) { | ||
| const { authToken, chittyId, entityType } = context; |
There was a problem hiding this comment.
Unused variable entityType.
| * @param {string} context.entityType - Type being minted (P/L/T/E/A) | |
| * @returns {Promise<TrustResolution>} | |
| */ | |
| async resolveTrustLevel(context) { | |
| const { authToken, chittyId, entityType } = context; | |
| * @returns {Promise<TrustResolution>} | |
| */ | |
| async resolveTrustLevel(context) { | |
| const { authToken, chittyId } = context; |
When ChittyMint is unavailable, ChittyID now issues fallback error IDs: - Error codes encoded in SSSS field (0000-0099 reserved) - Region 0, Jurisdiction ERR = error/pending ID - Error IDs stored in CHITTYID_PENDING KV for replacement - On validation, error IDs are detected and replaced with real IDs Error codes: - 0001: MINT_UNAVAILABLE - 0002: MINT_TIMEOUT - 0003: MINT_REJECTED - 0004: DRAND_UNAVAILABLE - 0005: CERT_UNAVAILABLE - 0006: TRUST_UNAVAILABLE - 0007: RATE_LIMITED - 0008: INVALID_REQUEST - 0099: INTERNAL_ERROR Addresses Code Cardinal finding #7: "CHARTER requires fallback mechanism" Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
worker.js (1)
22-41: Useenvparameter to accessCHITTYMINT_URLinstead ofprocess.env.With
compatibility_date = "2024-09-23", Wranglervarsbindings are not populated intoprocess.envby default. Theenvparameter passed to the fetch handler is the correct way to access them. Currently,process.env.CHITTYMINT_URLwill beundefinedat runtime, forcing the fallback URL. Passenvto a helper function or access it directly where needed.♻️ Proposed refactor
-const CHITTYMINT_URL = process.env.CHITTYMINT_URL || 'https://mint.chitty.cc'; +const DEFAULT_CHITTYMINT_URL = 'https://mint.chitty.cc'; +const getChittyMintUrl = (env) => env?.CHITTYMINT_URL || DEFAULT_CHITTYMINT_URL;
🤖 Fix all issues with AI agents
In `@worker.js`:
- Around line 42-79: generateFallbackErrorId currently mints ChittyIDs locally
(using ERROR_CODES and ENTITY_TYPES), which violates the rule that IDs must be
minted by the central service; replace the local minting with a call to the
central fallback ID service (e.g., request to fallback.id.chitty.cc or
id.chitty.cc) instead of constructing an ID string in generateFallbackErrorId,
rename/repurpose that function to something like requestFallbackIdFromService
and implement an async HTTP request that sends errorCode plus context
(originalRequest, entityType) and returns the service-provided ID, and if the
request fails return a structured error object ({ errorCode, message,
originalRequest }) or throw a handled error; update callers to await the new
async function and stop relying on local ERROR_CODES/ENTITY_TYPES encoding for
canonical IDs.
- Around line 451-509: The fallback re-mint path (inside the isErrorId block
that calls env.CHITTYID_PENDING and fetch(`${CHITTYMINT_URL}/api/mint`))
currently does an unguarded fetch; wrap this call with the same circuit-breaker
and timeout utilities used by your primary minting flow (reuse the existing
helpers used elsewhere for ChittyMint requests—e.g., the circuit breaker
instance and fetchWithTimeout/withCircuitBreaker wrapper) so that before calling
fetch you check the circuit state, run the mint request through the timeout
wrapper, and handle circuit-open/timeout errors by increasing pending.attempts
and persisting it (env.CHITTYID_PENDING.put) rather than attempting an unbounded
fetch; ensure the wrapper returns consistent error info so the existing
deletion/response logic (mintResult.chittyId, deletion of pending) still works
when successful.
♻️ Duplicate comments (3)
worker.js (3)
119-176: Add circuit breaker + timeout around the ChittyMint fetch.The outbound call is still unprotected, which risks cascading failures. Based on learnings, circuit breaking is required for ID generation.
239-239: Verify the 4‑digitYYMMrequirement is consistent across validators.This change will reject any 3‑digit
YYMvalues; please confirm the minting service and other validators are aligned before enforcing.#!/bin/bash # Locate other ChittyID validators and yearMonth patterns for consistency checks. rg -n "yearMonth|Year-?Month|YYMM|\\d\\{2,3\\}" --type=js --type=ts
435-435: Route/api/get-chittyidthrough the mandatory pipeline.This direct call still bypasses the required interception/enforcement stages. Based on learnings, all ID generation must pass the mandatory pipeline.
🧹 Nitpick comments (1)
wrangler.toml (1)
41-45: Use a dedicated KV namespace for pending fallback IDs.
CHITTYID_PENDINGis bound to the same namespace asCHITTYID_KV, which mixes canonical IDs with short‑lived fallback entries and makes retention/ACL policies harder to manage. Please provision a separate KV namespace and update both bindings accordingly.Also applies to: 86-90
| // Error code mapping for fallback IDs | ||
| // Encoded in SSSS field (0000-0099 reserved for error codes) | ||
| const ERROR_CODES = { | ||
| MINT_UNAVAILABLE: '0001', // ChittyMint service unreachable | ||
| MINT_TIMEOUT: '0002', // ChittyMint request timed out | ||
| MINT_REJECTED: '0003', // ChittyMint rejected the request | ||
| DRAND_UNAVAILABLE: '0004', // drand beacon unavailable | ||
| CERT_UNAVAILABLE: '0005', // ChittyCert unavailable | ||
| TRUST_UNAVAILABLE: '0006', // ChittyTrust unavailable | ||
| RATE_LIMITED: '0007', // Rate limit exceeded | ||
| INVALID_REQUEST: '0008', // Invalid mint request | ||
| INTERNAL_ERROR: '0099' // Unknown internal error | ||
| }; | ||
|
|
||
| // Entity type codes | ||
| const ENTITY_TYPES = { person: 'P', place: 'L', thing: 'T', event: 'E', authority: 'A' }; | ||
|
|
||
| /** | ||
| * Generate a fallback error ID | ||
| * Uses existing ChittyID format with error code encoded in SSSS field | ||
| * These IDs are replaced with real IDs on next verification attempt | ||
| */ | ||
| function generateFallbackErrorId(errorCode, entityType, originalRequest) { | ||
| const version = '03'; | ||
| const region = '0'; // Region 0 = Error/Pending | ||
| const jurisdiction = 'ERR'; // Reserved jurisdiction for errors | ||
| const sequential = ERROR_CODES[errorCode] || ERROR_CODES.INTERNAL_ERROR; | ||
| const type = ENTITY_TYPES[entityType?.toLowerCase()] || 'T'; | ||
| const now = new Date(); | ||
| const year = now.getFullYear().toString().slice(-2); | ||
| const month = (now.getMonth() + 1).toString().padStart(2, '0'); | ||
| return year + month.slice(1); | ||
| const yearMonth = now.getFullYear().toString().slice(-2) + (now.getMonth() + 1).toString().padStart(2, '0'); | ||
| const trustLevel = '0'; // Trust 0 = Unverified/Error | ||
|
|
||
| // Calculate checksum | ||
| const baseId = `${version}${region}${jurisdiction}${sequential}${type}${yearMonth}${trustLevel}`; | ||
| const checksum = mod97Checksum(baseId).toString().padStart(2, '0'); | ||
|
|
||
| return `${version}-${region}-${jurisdiction}-${sequential}-${type}-${yearMonth}-${trustLevel}-${checksum}`; | ||
| } |
There was a problem hiding this comment.
Avoid local fallback ID minting; delegate to the central service.
generateFallbackErrorId creates ChittyIDs locally, which can produce non‑canonical IDs and bypass centralized audit controls. Please obtain error/fallback IDs from the central infrastructure (e.g., id.chitty.cc / fallback.id.chitty.cc) or return a structured error without minting locally. As per coding guidelines, ChittyIDs must be minted via central services.
🤖 Prompt for AI Agents
In `@worker.js` around lines 42 - 79, generateFallbackErrorId currently mints
ChittyIDs locally (using ERROR_CODES and ENTITY_TYPES), which violates the rule
that IDs must be minted by the central service; replace the local minting with a
call to the central fallback ID service (e.g., request to fallback.id.chitty.cc
or id.chitty.cc) instead of constructing an ID string in
generateFallbackErrorId, rename/repurpose that function to something like
requestFallbackIdFromService and implement an async HTTP request that sends
errorCode plus context (originalRequest, entityType) and returns the
service-provided ID, and if the request fails return a structured error object
({ errorCode, message, originalRequest }) or throw a handled error; update
callers to await the new async function and stop relying on local
ERROR_CODES/ENTITY_TYPES encoding for canonical IDs.
|
|
||
| // Check if this is a fallback error ID that needs replacement | ||
| if (isErrorId(body.id)) { | ||
| const errorInfo = getErrorFromId(body.id); | ||
|
|
||
| // Try to get the original request and mint a real ID | ||
| if (env?.CHITTYID_PENDING) { | ||
| const pendingData = await env.CHITTYID_PENDING.get(body.id); | ||
| if (pendingData) { | ||
| const pending = JSON.parse(pendingData); | ||
|
|
||
| // Attempt to mint a real ID via ChittyMint | ||
| try { | ||
| const authHeader = request?.headers?.get('Authorization'); | ||
| const mintResponse = await fetch(`${CHITTYMINT_URL}/api/mint`, { | ||
| method: 'POST', | ||
| headers: { | ||
| 'Content-Type': 'application/json', | ||
| ...(authHeader ? { 'Authorization': authHeader } : {}) | ||
| }, | ||
| body: JSON.stringify(pending.originalRequest) | ||
| }); | ||
|
|
||
| if (mintResponse.ok) { | ||
| const mintResult = await mintResponse.json(); | ||
|
|
||
| // Delete the pending entry | ||
| await env.CHITTYID_PENDING.delete(body.id); | ||
|
|
||
| return new Response(JSON.stringify({ | ||
| success: true, | ||
| replaced: true, | ||
| oldId: body.id, | ||
| newId: mintResult.chittyId, | ||
| message: 'Fallback error ID has been replaced with a valid ChittyID', | ||
| ...mintResult, | ||
| timestamp: new Date().toISOString() | ||
| }), { | ||
| headers: { "Content-Type": "application/json", "Access-Control-Allow-Origin": "*" } | ||
| }); | ||
| } | ||
| } catch (e) { | ||
| // ChittyMint still unavailable - return error info | ||
| pending.attempts = (pending.attempts || 0) + 1; | ||
| await env.CHITTYID_PENDING.put(body.id, JSON.stringify(pending), { expirationTtl: 86400 * 7 }); | ||
| } | ||
| } | ||
| } | ||
|
|
||
| // Return error ID info if replacement failed | ||
| return new Response(JSON.stringify({ | ||
| success: true, | ||
| valid: false, | ||
| ...errorInfo, | ||
| timestamp: new Date().toISOString() | ||
| }), { | ||
| headers: { "Content-Type": "application/json", "Access-Control-Allow-Origin": "*" } | ||
| }); | ||
| } |
There was a problem hiding this comment.
Protect fallback replacement minting with circuit breaker + timeout.
The re‑mint path in validation performs an unguarded fetch. Please wrap it with the same circuit‑breaker/timeout safeguards used for primary minting to prevent cascading failures. Based on learnings, circuit breaking is required for ID generation.
🤖 Prompt for AI Agents
In `@worker.js` around lines 451 - 509, The fallback re-mint path (inside the
isErrorId block that calls env.CHITTYID_PENDING and
fetch(`${CHITTYMINT_URL}/api/mint`)) currently does an unguarded fetch; wrap
this call with the same circuit-breaker and timeout utilities used by your
primary minting flow (reuse the existing helpers used elsewhere for ChittyMint
requests—e.g., the circuit breaker instance and
fetchWithTimeout/withCircuitBreaker wrapper) so that before calling fetch you
check the circuit state, run the mint request through the timeout wrapper, and
handle circuit-open/timeout errors by increasing pending.attempts and persisting
it (env.CHITTYID_PENDING.put) rather than attempting an unbounded fetch; ensure
the wrapper returns consistent error info so the existing deletion/response
logic (mintResult.chittyId, deletion of pending) still works when successful.
|
@copilot In
|
|
@chitcommit I've opened a new pull request, #9, to work on those changes. Once the pull request is ready, I'll request review from you. |
Summary
Test plan
🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Bug Fixes
✏️ Tip: You can customize this high-level summary in your review settings.