tests(api) add script to test the claim token api #320
Conversation
akaladarshi
requested review from
Copilot,
elmattic and
sudo-shashank
and removed request for
Copilot
|
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. WalkthroughAdds a matrix-driven GitHub Actions e2e workflow that launches per-matrix Durable Object servers, restores caches, updates wasm tooling, runs k6 tests; adds k6 claim_token tests + config, makes e2e BASE_URL configurable, and adds an E2E API testing guide. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor GitHubActions as GitHub Actions (e2e-tests)
participant Runner as Job Runner
participant Cache as Cache Restore
participant Tooling as Wasm Tooling
participant Wrangler as wrangler dev (DO)
participant Readiness as Port/HTTP checks
participant K6 as k6 Runner
participant API as /api/claim_token
GitHubActions->>Runner: start matrix entry (Browser / API)
Runner->>Cache: restore cargo/npm/... caches
Runner->>Tooling: install wasm-opt, wasm-pack, worker-build
Runner->>Wrangler: wrangler dev --port matrix.port --state-dir matrix.state_dir
Wrangler->>Readiness: open port & serve HTTP
Readiness-->>Runner: port + HTTP ready
Runner->>K6: run matrix.script with API_URL=http://127.0.0.1:matrix.port
K6->>API: GET /api/claim_token?... (validation/rate-limit/wallet-cap)
alt success
API-->>K6: 200 + ethereum tx hash
else rate-limited / mainnet / error
API-->>K6: 429 / 418 / 4xx/5xx
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #320 +/- ##
=======================================
Coverage 39.37% 39.37%
=======================================
Files 40 40
Lines 2537 2537
=======================================
Hits 999 999
Misses 1538 1538 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
e2e/test_claim_token_api.js (2)
12-21: Consider adding threshold for error rate metric.The
errorRatemetric is tracked but has no threshold defined. Consider adding a threshold like'errors': ['rate<0.1']to fail the test if error rate exceeds 10%.Apply this diff:
export const options = { vus: 1, iterations: 1, thresholds: { 'http_req_duration': ['p(95)<5000'], + 'errors': ['rate<0.1'], }, };
23-30: Enhance Filecoin transaction hash validation.The Filecoin validation only checks length (46-70 characters) but doesn't verify the format. Filecoin CIDs typically start with
bafyfor base32-encoded multihash. Consider adding a prefix check for stronger validation.Apply this diff:
function validateTransactionHash(txHash, expectedFormat) { if (expectedFormat === 'ethereum') { return txHash.startsWith('0x') && txHash.length === 66; } else if (expectedFormat === 'filecoin') { - return txHash.length >= 46 && txHash.length <= 70; + return txHash.startsWith('bafy') && txHash.length >= 46 && txHash.length <= 70; } return false; }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.github/workflows/e2e.yml(1 hunks)e2e/test_claim_token_api.js(1 hunks)e2e/test_claim_token_api_config.js(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
e2e/test_claim_token_api.js (1)
e2e/test_claim_token_api_config.js (10)
API_CONFIG(2-10)API_CONFIG(2-10)FaucetTypes(34-39)FaucetTypes(34-39)TEST_ADDRESSES(12-32)TEST_ADDRESSES(12-32)STATUS_CODES(41-47)STATUS_CODES(41-47)TEST_SCENARIOS(50-194)TEST_SCENARIOS(50-194)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: codedov
- GitHub Check: lint
- GitHub Check: e2e
- GitHub Check: deploy
🔇 Additional comments (9)
.github/workflows/e2e.yml (1)
81-84: LGTM!The new workflow step correctly integrates the claim_token API tests into the CI pipeline using the same pattern as the existing k6 step.
e2e/test_claim_token_api_config.js (4)
34-47: LGTM!Faucet types and status codes are well-defined and align with the API requirements from issue #319.
99-193: Excellent rate-limiting test coverage.The test scenarios comprehensively cover rate limiting across different faucet types, address formats, and address equivalence (ETH ↔ t410). This aligns well with the requirements in issue #319.
54-74: Tests are correct: missing parameters yield 500 TheGetUrlextractor fails on absent query fields and surfaces them asINTERNAL_SERVER_ERROR, so keeping the tests’ expectations at 500 is accurate.
15-16: ETH_FORMAT_ADDRESS and T410_ADDRESS correctly correspond. No change required.e2e/test_claim_token_api.js (4)
32-52: LGTM!The request helper properly handles optional parameters, applies URL encoding, and configures timeouts and tags appropriately.
54-85: LGTM!Input validation tests comprehensively cover invalid addresses and malformed requests, addressing the requirements from issue #319 for testing
parse_and_validate_addressbehavior.
87-114: LGTM!Rate limiting tests thoroughly validate the 429 response requirement from issue #319, including transaction hash format verification for successful claims and proper handling of address equivalence.
116-119: LGTM!Test orchestration is clean and runs validation tests before rate limiting tests in a logical sequence.
akaladarshi
force-pushed
the
akaladarshi/claim-token-api-tests
branch
from
08faae4 to
a98ce34
Compare
akaladarshi
force-pushed
the
akaladarshi/claim-token-api-tests
branch
from
a98ce34 to
68b4178
Compare
akaladarshi
force-pushed
the
akaladarshi/claim-token-api-tests
branch
2 times, most recently
from
7604d27 to
54d2c5f
Compare
akaladarshi
force-pushed
the
akaladarshi/claim-token-api-tests
branch
from
54d2c5f to
bb16e24
Compare
akaladarshi
force-pushed
the
akaladarshi/claim-token-api-tests
branch
from
bad61b9 to
2fb3d4c
Compare
There was a problem hiding this comment.
Pull Request Overview
This PR adds comprehensive end-to-end testing for the claim token API using k6. The testing suite validates API behavior including input validation, rate limiting mechanisms, and response format verification across different faucet types and address formats.
- Implements k6 test script with configurable test scenarios for claim token API validation
- Adds comprehensive test cases covering invalid inputs, rate limiting behavior, and transaction hash validation
- Integrates new test suite into existing CI/E2E workflow for automated verification
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| e2e/test_claim_token_api_config.js | Configuration file defining test addresses, faucet types, status codes, and test scenarios |
| e2e/test_claim_token_api.js | Main test script implementing validation logic and test execution |
| .github/workflows/e2e.yml | CI workflow update to include the new claim token API test suite |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
e2e/test_claim_token_api.js (1)
95-108: AssertRetry-Afteron rate-limited responses.Issue #319 asks us to verify the retry-after messaging when rate limiting kicks in. We only assert the 429 status today, so the header/message could regress unnoticed. Please add a
checkthat inspectsresponse.headers['Retry-After'](or the equivalent body field if that’s how the API surfaces it).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.github/workflows/e2e.yml(1 hunks)e2e/test_claim_token_api.js(1 hunks)e2e/test_claim_token_api_config.js(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
e2e/test_claim_token_api.js (1)
e2e/test_claim_token_api_config.js (10)
API_CONFIG(2-10)API_CONFIG(2-10)FaucetTypes(34-39)FaucetTypes(34-39)TEST_ADDRESSES(12-32)TEST_ADDRESSES(12-32)STATUS_CODES(41-47)STATUS_CODES(41-47)TEST_SCENARIOS(50-165)TEST_SCENARIOS(50-165)
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
e2e/test_claim_token_api.js (3)
22-28: Redundant quote stripping suggests uncertainty about response format.The logic strips quotes twice (lines 22-24, then 26-28), which would only be necessary for triple-quoted strings like
"""hash""". This redundancy suggests uncertainty about the actual response format.Investigate the actual format returned by the API and simplify to a single stripping operation:
function validateTransactionHash(txHash) { - // Remove outer quotes if present if (txHash.startsWith('"') && txHash.endsWith('"')) { txHash = txHash.slice(1, -1); } - // Remove inner quotes if present - if (txHash.startsWith('"') && txHash.endsWith('"')) { - txHash = txHash.slice(1, -1); - } - - // Both CalibnetFIL and CalibnetUSDFC now return Ethereum format: 0x + 64 hex chars = 66 total return txHash.startsWith('0x') && txHash.length === 66; }Alternatively, if the API genuinely returns nested quotes, add a comment explaining why.
66-71: Consider extracting check name construction.The inline check name construction on line 67 works but reduces readability. Consider extracting it:
+ const checkName = `${faucetType} - Invalid address "${invalidAddress}" properly rejected (400 and error)`; check(response, { - [checkName]: (r) => + [checkName]: (r) => r.status === STATUS_CODES.BAD_REQUEST && r.body && r.body.toLowerCase().includes("invalid") });This makes the check assertion more readable while maintaining the same functionality.
120-121: Clarify the 5-second buffer in cooldown wait.The wait uses
FAUCET_COOLDOWN_BUFFER_SECONDS(65s) but doesn't explain the 5-second buffer beyond the 60-second cooldown. Consider improving the comment:- console.log(`⏰ Waiting ${API_CONFIG.FAUCET_COOLDOWN_BUFFER_SECONDS} seconds to ensure previous global faucet cooldowns have expired...`); + console.log(`⏰ Waiting ${API_CONFIG.FAUCET_COOLDOWN_BUFFER_SECONDS} seconds (60s cooldown + 5s buffer) to ensure previous faucet cooldowns have expired...`);This makes the buffer explicit in the log message, helping future maintainers understand why it's not exactly 60 seconds.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
e2e/test_claim_token_api.js(1 hunks)e2e/test_claim_token_api_config.js(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- e2e/test_claim_token_api_config.js
🧰 Additional context used
🧬 Code graph analysis (1)
e2e/test_claim_token_api.js (1)
e2e/test_claim_token_api_config.js (10)
API_CONFIG(2-12)API_CONFIG(2-12)FaucetTypes(36-41)FaucetTypes(36-41)TEST_ADDRESSES(14-34)TEST_ADDRESSES(14-34)STATUS_CODES(43-49)STATUS_CODES(43-49)TEST_SCENARIOS(52-167)TEST_SCENARIOS(52-167)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: deploy
- GitHub Check: lint
- GitHub Check: codedov
- GitHub Check: e2e
🔇 Additional comments (3)
e2e/test_claim_token_api.js (3)
1-18: LGTM! Clean test setup.The k6 imports and options configuration are well-structured. Single VU and iteration ensure deterministic sequential execution, which is appropriate for testing rate-limiting behavior that depends on order.
34-53: LGTM! Proper URL construction and request handling.The function correctly handles optional parameters, applies URL encoding, and configures appropriate timeout and tags for the HTTP request.
90-116: LGTM! Thorough rate-limiting test coverage.The test suite properly validates both successful claims and rate-limited rejections, validates transaction hashes on success, and includes helpful debug logging. The 0.5-second sleep between requests is appropriate pacing.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
e2e/test_claim_token_api.js (2)
20-32: Clarify or fix duplicate quote-removal logic.Lines 22-23 and 26-27 contain identical logic for removing quotes. If this is intentional to handle doubly-nested quotes, add a comment explaining why. Otherwise, this appears to be a copy-paste error. Typically, you'd only need to remove quotes once.
Apply this diff to simplify the function:
function validateTransactionHash(txHash) { // Remove outer quotes if present if (txHash.startsWith('"') && txHash.endsWith('"')) { txHash = txHash.slice(1, -1); } - // Remove inner quotes if present - if (txHash.startsWith('"') && txHash.endsWith('"')) { - txHash = txHash.slice(1, -1); - } // Both CalibnetFIL and CalibnetUSDFC now return Ethereum format: 0x + 64 hex chars = 66 total return txHash.startsWith('0x') && txHash.length === 66; }
162-162: Add semicolon for consistency.Line 162 is missing a semicolon after
testWalletCap(). While JavaScript doesn't strictly require it, adding one would maintain consistency with the rest of the codebase.testRateLimiting(); - testWalletCap() + testWalletCap(); console.log('\n✅ All tests passed successfully!');
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
e2e/test_claim_token_api.js(1 hunks)e2e/test_claim_token_api_config.js(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
e2e/test_claim_token_api.js (1)
e2e/test_claim_token_api_config.js (10)
API_CONFIG(2-12)API_CONFIG(2-12)FaucetTypes(36-41)FaucetTypes(36-41)TEST_ADDRESSES(14-34)TEST_ADDRESSES(14-34)STATUS_CODES(43-49)STATUS_CODES(43-49)TEST_SCENARIOS(52-305)TEST_SCENARIOS(52-305)
e2e/test_claim_token_api.js
Outdated
| // Remove inner quotes if present | ||
| if (txHash.startsWith('"') && txHash.endsWith('"')) { | ||
| txHash = txHash.slice(1, -1); | ||
| } |
There was a problem hiding this comment.
looks like duplicate code, do we need both?
There was a problem hiding this comment.
Maybe use txHash.replace(/^"|"$/g, ''); ?
There was a problem hiding this comment.
Comment mentions this, outer quotes and inner quotes
e2e/test_claim_token_api.js
Outdated
|
|
||
| export default function () { | ||
| testInputValidation(); | ||
| console.log(`⏰ Waiting ${API_CONFIG.FAUCET_COOLDOWN_BUFFER_SECONDS} seconds to ensure previous global faucet cooldowns have expired...`); |
There was a problem hiding this comment.
in the beginning of the test no rate limiter should be active, then do we need this wait for cooldowns
There was a problem hiding this comment.
We are also running the e2e/scripts before e2e/test_claim_token_api.js and it contains a test for sending a transaction.
e2e/test_claim_token_api_config.js
Outdated
| F1_FORMAT_ADDRESS: 'f15ydyu3d65gznpp2qxwpkjsgz4waubeunn6upvla', | ||
| T1_FORMAT_ADDRESS: 't15ydyu3d65gznpp2qxwpkjsgz4waubeunn6upvla', | ||
| T410_ADDRESS: 't410fw6vb5heeptnf6yhrvzxwlq7k4reerva7p667swi', | ||
| ETH_FORMAT_ADDRESS: '0xb7aA1e9c847CDA5F60f1AE6f65C3eae44848D41f', | ||
| T0_ADDRESS: 't0175013', | ||
| ETH_ID_CORRESPONDING: '0xff0000000000000000000000000000000002aba5', |
There was a problem hiding this comment.
are these the same address we have configured in e2e test?
There was a problem hiding this comment.
No, actually these address are of main private key which we use to sign the calibnet transaction.
There was a problem hiding this comment.
let's use the ones we have in e2e test as those were created for this purpose only
There was a problem hiding this comment.
The issue with them is that we are already are doing some transaction in the e2e/script which makes it rate limit, so we can't really test it here.
There was a problem hiding this comment.
we will be having one success claim test in e2e test for each of the faucet. In your test you can still test rate limiter and wallet capped both together
or reset the rate limiter and then run your test in CI
or run both e2e and this new test parallel in separate workflows
but in my view we should be using test wallet we have created and use them only in testing
e2e/test_claim_token_api.js
Outdated
| url += `?${params.join('&')}`; | ||
| } | ||
|
|
||
| return http.get(url, { |
There was a problem hiding this comment.
Let's handle network errors (e.g., timeouts, connection failures) explicitly using k6’s check or try-catch?
| T0_ADDRESS: 't0175013', | ||
| ETH_ID_CORRESPONDING: '0xff0000000000000000000000000000000002aba5', | ||
|
|
||
| INVALID: [ |
There was a problem hiding this comment.
nit: add edge cases like malformed Ethereum addresses (e.g., 0x + 63 chars) or Filecoin addresses with invalid checksums.
| }); | ||
| } | ||
|
|
||
| function testWalletCap() { |
There was a problem hiding this comment.
I would be great to have doc comments explaining the test flow.
| console.log('✅ Input validation tests completed'); | ||
| } | ||
|
|
||
| function testRateLimiting() { |
There was a problem hiding this comment.
testRateLimiting and testWalletCap both are logically doing similar operation or steps, can we introduce some common helper function which can be used in both these checks
There was a problem hiding this comment.
RateLimiting actually testing only the RATE_LIMIT_TEST_COOLDOWN_CASES checks (we are not waiting here), testWalletCap is waiting for cooldown period to get over, that's why I wrote them separately so it will be easier to read.
I can add common step where we are passing cooldown as 0 in RATE_LIMIT_TEST_COOLDOWN_CASES tests but it will become little confusing.
There was a problem hiding this comment.
const response = makeClaimRequest(testCase.faucet_info, testCase.address);
const statusCheckName = `${testCase.name}: Expected ${testCase.expectedStatus}, got ${response.status}`;
check(response, {
[statusCheckName]: (r) => r.status === testCase.expectedStatus,
});
if (response.status === STATUS_CODES.SUCCESS) {
const hashCheckName = `${testCase.name}: ✅ Valid transaction hash`;
check(response, {
[hashCheckName]: (r) => validateTransactionHash(r.body.trim()),
});
}
// Log results for debugging
if (response.status !== testCase.expectedStatus) {
console.log(`❌ ${testCase.name}: Expected ${testCase.expectedStatus}, got ${response.status} - ${response.body}`);
}
we have a bit of code which is common between both of these checks
akaladarshi
force-pushed
the
akaladarshi/claim-token-api-tests
branch
3 times, most recently
from
3449fab to
60fde64
Compare
akaladarshi
force-pushed
the
akaladarshi/claim-token-api-tests
branch
from
60fde64 to
3abef0e
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
e2e/script.js (1)
21-21: LGTM with optional formatting improvement.The environment-driven URL configuration is correct and aligns with the workflow changes.
Optionally add a space after
||for consistency with JavaScript style guides:-const BASE_URL = __ENV.API_URL ||"http://127.0.0.1:8787"; +const BASE_URL = __ENV.API_URL || "http://127.0.0.1:8787";e2e/test_claim_token_api.js (1)
148-156: Consider strengthening retry time validation.The regex
parseInt((r.body.match(/(\d+)/) || [null, 0])[1])extracts the first number from the response but doesn't validate that it's actually the retry-after value or that the response format is correct.Consider making the extraction more robust:
- const retrySeconds = parseInt((r.body.match(/(\d+)/) || [null, 0])[1]); + // Look for patterns like "retry after 3665 seconds" or similar + const match = r.body.match(/retry\s+(?:after|in)\s+(\d+)\s+seconds?/i); + if (!match) { + console.log(`⚠️ Could not parse retry time from: ${r.body}`); + return false; + } + const retrySeconds = parseInt(match[1]); return retrySeconds > 3600;.github/workflows/e2e.yml (1)
37-41: Set k6_browser_enabled to false for API Tests
Thee2e/test_claim_token_api.jsscript doesn’t import or use any browser APIs, so disabling browser mode reduces unnecessary overhead.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
.github/workflows/e2e.yml(4 hunks)e2e/script.js(1 hunks)e2e/test_claim_token_api.js(1 hunks)e2e/test_claim_token_api_config.js(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
e2e/test_claim_token_api.js (1)
e2e/test_claim_token_api_config.js (10)
STATUS_CODES(72-78)STATUS_CODES(72-78)API_CONFIG(2-13)API_CONFIG(2-13)FaucetTypes(65-70)FaucetTypes(65-70)TEST_ADDRESSES(15-63)TEST_ADDRESSES(15-63)TEST_SCENARIOS(81-334)TEST_SCENARIOS(81-334)
🔇 Additional comments (6)
e2e/test_claim_token_api_config.js (1)
1-334: LGTM!The configuration is comprehensive and well-structured. Past reviewer concerns have been addressed:
- BASE_URL correctly defaults to local test server
- Status codes confirmed correct for Leptos server function behavior
- Edge cases for malformed addresses included
The test scenarios provide thorough coverage of invalid requests, rate limiting, and wallet cap functionality.
.github/workflows/e2e.yml (1)
25-118: LGTM!The matrix-driven workflow design is excellent:
- Parallel execution of browser and API tests
- Per-matrix state directories prevent Durable Object conflicts
- Robust readiness checks (TCP port + HTTP)
- Proper caching for dependencies
The workflow orchestration correctly exposes
API_URLto tests and uses configurable ports per matrix entry.e2e/test_claim_token_api.js (4)
20-25: LGTM!The transaction hash validation correctly checks for Ethereum format (0x prefix + 64 hex characters).
27-69: LGTM!The
runTestScenarioshelper is well-designed with:
- Conditional waiting support for rate limit tests
- Primary status check before additional validations
- Extensible additional checks via callback
- Clear logging on failures
This refactoring addresses previous reviewer feedback about code duplication.
71-99: LGTM!The
makeClaimRequestfunction includes comprehensive network-level checks:
- Response received (status !== 0)
- No network errors
- Within timeout threshold
The request descriptor provides useful debugging context.
164-196: LGTM!The main function includes:
- Robust server connectivity retry logic (up to 3 attempts with delays)
- Clear console output for debugging
- Proper error handling and early return on connection failure
- Sequential execution of all test suites
The retry approach aligns with how browser tests handle initial server readiness.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
docs/e2e_api_testing_guide.md(1 hunks)e2e/test_claim_token_api.js(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- docs/e2e_api_testing_guide.md
🧰 Additional context used
🧬 Code graph analysis (1)
e2e/test_claim_token_api.js (1)
e2e/test_claim_token_api_config.js (10)
STATUS_CODES(72-78)STATUS_CODES(72-78)API_CONFIG(2-13)API_CONFIG(2-13)FaucetTypes(65-70)FaucetTypes(65-70)TEST_ADDRESSES(15-63)TEST_ADDRESSES(15-63)TEST_SCENARIOS(81-334)TEST_SCENARIOS(81-334)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: codedov
- GitHub Check: E2E API Tests
- GitHub Check: E2E Browser Tests
- GitHub Check: deploy
| function validateTransactionHash(txHash) { | ||
| // Remove outer quotes if present | ||
| txHash = txHash.replace(/^"|"$/g, ''); | ||
| // Both CalibnetFIL and CalibnetUSDFC now return an Ethereum format: 0x + 64 hex chars = 66 total | ||
| return txHash.startsWith('0x') && txHash.length === 66; | ||
| } |
There was a problem hiding this comment.
Strengthen transaction-hash validation.
Only checking the 0x prefix and length lets something like 0xZZ… pass, so the test could report success even if the API returns a malformed hash. Enforce the hexadecimal character set to keep this guard meaningful.
- return txHash.startsWith('0x') && txHash.length === 66;
+ return /^0x[0-9a-fA-F]{64}$/.test(txHash);📝 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.
| function validateTransactionHash(txHash) { | |
| // Remove outer quotes if present | |
| txHash = txHash.replace(/^"|"$/g, ''); | |
| // Both CalibnetFIL and CalibnetUSDFC now return an Ethereum format: 0x + 64 hex chars = 66 total | |
| return txHash.startsWith('0x') && txHash.length === 66; | |
| } | |
| function validateTransactionHash(txHash) { | |
| // Remove outer quotes if present | |
| txHash = txHash.replace(/^"|"$/g, ''); | |
| // Both CalibnetFIL and CalibnetUSDFC now return an Ethereum format: 0x + 64 hex chars = 66 total | |
| return /^0x[0-9a-fA-F]{64}$/.test(txHash); | |
| } |
🤖 Prompt for AI Agents
In e2e/test_claim_token_api.js around lines 20 to 25, the
validateTransactionHash function only checks prefix and length which allows
non-hex chars; strip outer quotes as before then validate against a stricter
regex such as /^0x[0-9a-fA-F]{64}$/ to ensure the string starts with 0x and the
remaining 64 characters are valid hexadecimal; update the return to use that
regex (and ensure txHash is coerced to string before testing if necessary).
|
|
||
| ### 1. Connectivity Check | ||
|
|
||
| Before running tests, `validateServerConnectivity()` confirms the server is |
There was a problem hiding this comment.
do we have this function in test_claim_token_api.js?
| console.log('🔗 Checking server connectivity...'); | ||
|
|
||
| let healthResponse; | ||
| let attempts = 0; | ||
| const maxAttempts = 3; | ||
|
|
||
| while (attempts < maxAttempts) { | ||
| attempts++; | ||
| healthResponse = http.get(API_CONFIG.BASE_URL, { timeout: '10s' }); | ||
|
|
||
| if (healthResponse.status !== 0 && !healthResponse.error) { | ||
| console.log('✅ Server connectivity confirmed'); | ||
| break; | ||
| } | ||
|
|
||
| if (attempts < maxAttempts) { | ||
| console.log(`⏳ Server not ready (attempt ${attempts}/${maxAttempts}), waiting 5s...`); | ||
| sleep(5); | ||
| } | ||
| } | ||
|
|
||
| if (healthResponse.status === 0 || healthResponse.error) { | ||
| console.error(`❌ Server not reachable after ${maxAttempts} attempts: ${healthResponse.error || 'Connection failed'}`); | ||
| return; | ||
| } |
There was a problem hiding this comment.
as mentioned in the e2e_api_testing_guide.md I guess this could be a helper function validateServerConnectivity
4 participants
Summary of changes
Changes introduced in this pull request:
claim_tokenAPIReference issue to close (if applicable)
Closes #319
Other information and links
Change checklist
adheres to the team's
documentation standards,
(if possible),
should be reflected in this document.
Summary by CodeRabbit
Tests
Chores
Documentation