Conversation
…offchain proposals
Offchain votes
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ab3da07378
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if [ "$USE_RAILWAY" = true ]; then | ||
| log "railway_run: pnpm railway run -e dev -s $service $*" | ||
| pnpm railway run -e dev -s "$service" "$@" |
There was a problem hiding this comment.
Apply parsed overrides when launching services via Railway
railway_run parses KEY=VALUE overrides into overrides, but the --rw path never applies them before executing pnpm railway run. In this commit, Gateway relies on this mechanism to override DAO_API_* to localhost; without it, running scripts/dev.sh --rw <dao> keeps Railway-provided API URLs and routes traffic to remote APIs instead of the locally started API, which breaks local end-to-end validation.
Useful? React with 👍 / 👎.
| GATEWAY_READY=$(mktemp) | ||
| rm -f "$GATEWAY_READY" | ||
| log "Starting Gateway..." | ||
| GATEWAY_OVERRIDES=() | ||
| declare -a GATEWAY_OVERRIDES=() | ||
| if [ "$RUN_API" = true ]; then | ||
| GATEWAY_OVERRIDES+=("DAO_API_${DAO_ID}=http://localhost:${PORT_API}") |
There was a problem hiding this comment.
Uppercase DAO env suffix when building Gateway override
The Gateway override is built as DAO_API_${DAO_ID}, but DAO_ID is now derived from dao_id_for() as lowercase values like uni/gtc. The API-Gateway resolver looks up DAO clients using uppercase IDs (daoId.toUpperCase()), so this lowercase override does not match the expected DAO_API_UNI-style variable and the local API mapping is missed in --rw workflows.
Useful? React with 👍 / 👎.
feat: thresholds
fix(spp): improve mobile UI for service providers page
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1d57d25ff0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| export const TokenHistoricalPriceRequest = z | ||
| .object({ | ||
| skip: paginationSkipQueryParam(), | ||
| limit: paginationLimitQueryParam(), |
There was a problem hiding this comment.
Restore 365-point default for historical token data
Replacing the explicit limit default with paginationLimitQueryParam() changes /token/historical-data from returning 365 points by default to 10, because the shared helper defaults to 10. Existing callers rely on the endpoint default (for example useDaoTokenHistoricalData passes limit: null), so this truncates long-range charts and analytics unless every client is updated to always send an explicit limit.
Useful? React with 👍 / 👎.
| # 3. Gateway | ||
| # 3. Address Enrichment (always runs with railway env injection) | ||
| log "Starting Address Enrichment..." | ||
| run_with_prefix "$C_ADDRESS_ENRICHMENT" "💰 enrichment" "" "" pnpm railway run -e dev -s address-enrichment pnpm address dev & |
There was a problem hiding this comment.
Respect --rw flag when starting address enrichment
The script now starts address enrichment through pnpm railway run unconditionally, even when USE_RAILWAY is false, and immediately waits for its port. In local setups without Railway authentication/service access, that subprocess exits and wait_for_port times out, so scripts/dev.sh fails to boot despite not requesting Railway mode.
Useful? React with 👍 / 👎.
Offchain votes choices
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c3521a2602
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| includeOptimisticProposals: z.coerce | ||
| .boolean() | ||
| .optional() |
There was a problem hiding this comment.
Parse includeOptimisticProposals without boolean coercion
z.coerce.boolean() treats any non-empty string as true, so a request like includeOptimisticProposals=false is parsed as true and the exclusion branch in ProposalsService never runs. This breaks the documented filter behavior for REST callers (and GraphQL gateway calls that serialize booleans into query strings) whenever clients explicitly disable optimistic proposals.
Useful? React with 👍 / 👎.
| addresses: z | ||
| .array(AddressSchema) | ||
| .min(1, "At least one address is required") |
There was a problem hiding this comment.
Accept singleton address input for /addresses query
The batch enrichment query schema now only accepts an array, but query parsing commonly yields a single string when one addresses parameter is provided (for example /addresses?addresses=0x...). This makes single-address batch requests fail validation with 400, even though this endpoint previously supported that form and the OpenAPI description still says a single value is valid.
Useful? React with 👍 / 👎.
No description provided.