Fix #610, #613, #614: creator search test, webhook URL validation, cursor edge case#616
Merged
Chucks1093 merged 1 commit intoJul 24, 2026
Conversation
…ebhook URL validation (closes accesslayerorg#610, accesslayerorg#613, accesslayerorg#614) accesslayerorg#614 — cursor.utils.test.ts already comprehensively covered round-trip correctness and every malformed/tampered/empty-input case via CursorChecksumError assertions. Added the one gap against accesslayerorg#614's acceptance criteria: a payload with special characters (spaces, slashes, unicode). Note: accesslayerorg#614 describes decodeCursor as "returning null" for invalid input, but the actual (and better) design throws a typed CursorChecksumError, already exercised by 7 existing tests in this file — kept that real behavior rather than asserting a null-return that doesn't match the implementation. accesslayerorg#610 — Added creator-list-search-filter.integration.test.ts following the existing real-DB pattern used by sibling tests in this module (e.g. creator-list-price-filter.integration.test.ts): seeds three creators (Alpha, AlphaTwo, Beta) via Prisma and asserts against the real GET /api/v1/creators?search= endpoint — partial match returns both Alpha and AlphaTwo while excluding Beta, matching is case-insensitive, and an empty search string returns all seeded creators. accesslayerorg#613 — Found that CreateWebhookSchema only checked z.string().url(), which accepts plain-HTTP and hostless URLs (verified: 'http://example.com' and 'https://' both passed before this change). Added two refinements requiring https: protocol and a non-empty hostname, each with its own field-level error message. Added webhook-registration-url-validation.integration.test.ts covering: http:// rejected 400, no-host https:// rejected 400, non-URL string rejected 400, valid HTTPS accepted 201, and field-level error message assertion via res.body.error.details[].field. Confirmed no existing test breaks — the one place callback_url is ever a plain http:// value (webhook.integration.test.ts's retry test) writes directly via prisma.webhook.create, bypassing this schema entirely. Verification note: could not run the two new integration tests against a real Postgres in this environment (no Docker, no local Postgres, and completing a Homebrew install would have required a system-directory chown I didn't want to do unprompted). Verified via `tsc --noEmit` (clean) and `eslint` (clean) instead, confirmed both new test files fail with a DB-connectivity error (not a type/logic error) when run without a database, and confirmed the webhook schema change's exact accept/reject behavior with a standalone Node script exercising the zod schema directly.
|
@abayomicornelius Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #610
Closes #613
Closes #614
Closes #614
Summary
isValidStellarAddress/StellarAddressSchemaalready exist inwallet/wallet.utils.ts/wallet.schemas.ts, are already applied across every active endpoint that accepts an address (alerts,wallets/*,webhooks/webhook-signature.middleware.ts), and already have a comprehensive unit test file (wallet/__tests__/wallet.utils.test.ts, referencing issue Add helper for validating Stellar wallet address format before database queries #447) covering exactly the 4 acceptance-criteria cases this issue asks for. This issue appears to already be resolved by prior work.cursor.utils.test.tsalready comprehensively covered round-trip correctness and every malformed/empty/tampered-input case (viaCursorChecksumError, not a null return — see note below). Added the one missing case: a payload with special characters (spaces, slashes, unicode) surviving the round trip.creator-list-search-filter.integration.test.tsfollowing the existing real-DB pattern (creator-list-price-filter.integration.test.ts): seedsAlpha/AlphaTwo/Beta, assertsGET /api/v1/creators?search=alphareturns the first two and excludesBeta, case-insensitively, and that an empty search returns all seeded creators.CreateWebhookSchemaonly checkedz.string().url(), which accepts plain-HTTP and hostless URLs ('http://example.com'and'https://'both passed before this change — verified directly). Added two.refine()checks requiringhttps:protocol and a non-empty hostname, each with a distinct field-level message. Addedwebhook-registration-url-validation.integration.test.tscovering all 5 acceptance-criteria cases, following the exact auth-signing and error-shape (res.body.error.details[].field) conventions already used elsewhere in this module.Note on #614's "returns null" premise
The issue describes
decodeCursoras returningnullfor invalid/empty input. The actual implementation throws a typedCursorChecksumErrorinstead — a deliberate, arguably better design (silentnullon tampered input is easy to mishandle upstream). Kept the real, already-tested behavior rather than asserting a false premise.Test plan
tsc --noEmit— clean across the whole projecteslinton all touched/created files — cleanpnpm test(full suite) — same DB-connectivity failures before and after this branch for every test needing Postgres (172 failing due toCan't reach database server at localhost:5432— no Postgres available in this sandbox: no Docker, no local install, and completing a Homebrew install would have required asudo chownon a system directory I didn't want to do unprompted). Confirmed the 2 new integration tests fail with that same DB-connectivity error, not a type or logic error.http://rejected,https://with no host rejected, validhttps://...accepted) with a standalone Node script exercising the zod schema directlyhttp://callbackUrlappears (webhook.integration.test.ts's retry-delivery test) writes directly viaprisma.webhook.create, bypassingCreateWebhookSchemaentirelygit stashshowing identical failures pre-existing onmain)