feat: add support_email to /info response#175
Conversation
There was a problem hiding this comment.
Code Review
This pull request adds a support_email field to the /info endpoint and includes integration tests for its configuration. It also introduces a local expectTypeOf shim in test files. The review feedback recommends extracting the duplicated shim into a shared utility and refactoring repetitive test setup and teardown logic to improve maintainability.
| it('2b) /info includes support_email when configured', async () => { | ||
| const customDbUrl = makeSqliteDbUrlForTests(); | ||
| const customAnchor = createAnchor({ | ||
| network: { network: 'testnet' }, | ||
| server: {}, | ||
| security: { | ||
| sep10SigningKey: sep10ServerKeypair.secret(), | ||
| interactiveJwtSecret: 'jwt-test-secret-email', | ||
| distributionAccountSecret: 'distribution-test-secret', | ||
| }, | ||
| assets: { | ||
| assets: [ | ||
| { | ||
| code: 'USDC', | ||
| issuer: 'GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5', | ||
| }, | ||
| ], | ||
| }, | ||
| operational: { supportEmail: 'support@example.com' }, | ||
| framework: { | ||
| database: { provider: 'sqlite', url: customDbUrl }, | ||
| }, | ||
| }); | ||
|
|
||
| await customAnchor.init(); | ||
| const customInvoke = createMountedInvoker(customAnchor); | ||
| const response = await customInvoke({ path: '/info' }); | ||
| expect(response.status).toBe(200); | ||
| expect(response.body.support_email).toBe('support@example.com'); | ||
|
|
||
| await customAnchor.shutdown(); | ||
| const customDbPath = customDbUrl.startsWith('file:') | ||
| ? customDbUrl.slice('file:'.length) | ||
| : customDbUrl; | ||
| try { unlinkSync(customDbPath); } catch { /* ignore */ } | ||
| }); |
There was a problem hiding this comment.
The setup and teardown logic for customAnchor instances (creation, initialization, invocation, shutdown, and database cleanup) is repeated in this test and in test 2d. This boilerplate can make tests harder to read and maintain. Consider extracting this repetitive logic into a helper function or utilizing beforeEach/afterEach blocks for better test organization.
| /** | ||
| * Runtime no-op that preserves compile-time type assertions. | ||
| * Bun's test runner does not support vitest's `expectTypeOf` at runtime, | ||
| * so we use this shim instead. TypeScript still validates the type | ||
| * relationships at compile time via the generic constraints. | ||
| */ | ||
| function expectTypeOf<T>(_value: T) { | ||
| return { | ||
| toEqualTypeOf<U>(_?: U): void {}, | ||
| toMatchTypeOf<U>(_?: U): void {}, | ||
| }; |
There was a problem hiding this comment.
|
Please fix ci |
Summary
The
/inforoute already exposes the anchor name and asset list, but it does not expose a configured support email. A small support contact field makes the route more useful to integrators and testers without changing any core runtime behavior.What changed
src/runtime/http/express-router.ts/infohandler to build the response as a mutableRecord<string, unknown>and conditionally appendsupport_emailonly whenfullConfig.operational?.supportEmailis a non-empty string. Empty string is treated as not configured.No changes to
src/core/config.tsorsrc/types/config.ts—operational.supportEmailwas already typed asstring | undefined.Acceptance criteria
/infoTests
tests/mvp-express.integration.test.ts— 3 new focused integration tests:operational.supportEmail: 'support@example.com'→GET /infobody containssupport_emailequal to the configured valueoperational.supportEmail→GET /infobody does not containsupport_emailoperational.supportEmail: ''→GET /infobody does not containsupport_emailtests/info-support-email.property.test.ts— 2 property-based tests (100 runs each, usingfast-check):GET /inforeturnssupport_emailequal to that exact string with status 200undefinedor"",GET /infodoes not includesupport_emailin the response bodyClose #84