Conversation
The opportunistic in-range path quoted, sized, and balance-checked a fresh USDC->BRLA->USDC run before the state machine got a chance to resume a run that died mid-flow. With the in-flight USDC no longer in the wallet, that balance check failed on every cron run and the stuck state was never resumed. The out-of-range path had its own resume check; hoist a single one to the top of checkForRebalancing for both Base flows. Also stop selecting the profitable USDC->BRLA amount when the Base USDC balance cannot fund it: fall back to the standard amount instead of crashing after two quote round-trips.
Dry-run by default: prints the persisted USDC->BRLA->USDC state from Supabase Storage. With --confirm it resets the phase to idle while keeping history, for runs whose funds were reconciled manually.
…ming Resuming a persisted run in dry-run mode would write state and move funds during an invocation the spec defines as read-only, and resuming before the coverage read let funds move when the indexer read would have failed. Both were latent on the out-of-range paths before the resume was hoisted.
The reset script and a live run write the same Supabase object without locking, and the script's closing message contradicted the README's reconcile-first order.
Continuing into the fresh evaluation quoted and sized a run that assumes the in-flight USDC is still in the wallet, and logged "no rebalancing needed" while a run was paused.
The affordability gate read the wallet balance even when the policy mode is off, which the spec defines as returning before any balance read. The resume-before-fresh-evaluation ordering, the dry-run pause, the --restart bypass and the profitable-amount gate had no automated coverage because index.ts runs the cycle at import. Move that orchestration into rebalanceCycle.ts behind injected dependencies so a later refactor cannot silently reorder it.
…-flight Resume in-flight rebalancer runs before sizing a fresh one
A non-JSON error response from Squidrouter (a Cloudflare or load-balancer
error page) was collapsed to `{}` and the HTTP status was not logged, so
production logs showed "Error fetching route from Squidrouter API: {}"
with no way to tell what the upstream actually returned.
The nightly e2e smoke test failed because production's POST /v1/quotes answered 500: Squidrouter's /route endpoint returned a non-JSON 5xx from the gateway in front of it. Production logs show this ~1-2 times per hour, each one a user-facing 500, while the same request succeeds a second later. Extend the existing retry-once path (previously only for rate limits) to a 5xx whose body is not Squid's JSON error shape. Squid's own deterministic errors, such as low liquidity, keep failing fast without a retry.
…e read `response.text()` rejects when the gateway truncates the error stream. That escaped as a bare TypeError, losing the HTTP status and skipping the gateway retry, whereas the previous `.json().catch()` still produced an HttpError. Treat an unreadable body as empty so the status is logged and a 5xx is still retried.
…y spec The Squid integration spec said only 429s are retried and every other error fails fast. It also described the 429 handling as exponential backoff, whereas `getRoute` retries once after the advertised retryAfter.
…retry Retry Squidrouter route requests that fail at the gateway
The hook is a leftover from the standalone rebalancer repo. Run from apps/rebalancer, husky 9 stops at ".git can't be found", so it never installed anything; the root prepare already installs the hooks for the whole repo. Because the rebalancer does not depend on husky, bun can also run the hook before the root's binary is linked, which fails a cold `bun install --frozen-lockfile` with exit 127, as seen in CI and in `bun bootstrap:worktree`.
…pare Remove the rebalancer's redundant husky prepare hook
The API rejects with "Invalid pixKey or receiverTaxId." (trailing period), so the exact-match comparison never fired and server-side rejections surfaced as a generic VortexSdkError.
GET /v1/ramp/{id}?showUnsignedTxs=true returned the raw unsignedTxs, so a
client could fetch the user's source-of-funds transactions for a SELL ramp
before every ephemeral presign was received and validated, bypassing the
gate that register and update enforce.
…apping Map the API's invalid pixKey rejection to InvalidPixKeyError in the SDK
The release gate only filters SELL responses, so validating presigns for a BUY status request added latency and a chain API dependency for nothing.
Integrators only found the programmatic OTP route, so point Quick Start and AI Agent Integration at the dashboard steps in Authentication.
The release case persisted presignChecksPass, so it short-circuited before ephemeralPresignChecksPass and a regression dropping the dynamic check would have stayed green while SELL clients never received their transactions.
The API releases achPaymentData on the first ramp update and on status; the start response never carries it, so integrators following the docs read undefined.
Self-ramping integrators had to infer from managed-profile pages that they need no child profiles; spell out the setup and per-ramp sequence and link it from Quick Start.
SimpleStatus described COMPLETED, but every ramp response maps phases to TransactionStatus, which returns COMPLETE, so spec-following clients never detected completion.
The skill still called listAlfredpayFiatAccounts, which no longer exists, passed an alpha-3 country, and read a nonexistent id field, so its sell recipe could not run.
Public docs name corridors, not providers, and the fiat-account note now points to the SDK method that returns the ID.
…gate Apply the SELL release gate to the ramp status endpoint
✅ Deploy Preview for vrtx-dashboard canceled.
|
✅ Deploy Preview for vortex-sandbox ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for vortexfi ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Pages disagreed on EUR: some described out-of-band provisioning with no SDK support, others a live SDK flow. The published SDK 0.9.0 has no EUR support and production is not yet activated, so every page now says sandbox now, production pending, SDK support in the next release. The same passages now say 'EUR provider' in prose while released routes, error codes and phase values keep their names, as recorded in the README exceptions.
The skill told agents EUR BUY is active through the SDK, which neither npm 0.9.0 nor production supports yet.
The business EUR onramp account and its deposit events share the EUR provider activation that production is still waiting on, so they carry the same sandbox note as EUR buys.
Review found the own-account path sent EUR users to production keys, skipped EUR wallet linking and IBAN provisioning, omitted the country for the payout-account lookup, did not say direct clients sign the ephemeral transactions, and assumed verification creates the payout account.
The API derives the EUR permit owner from the provider binding and ignores walletAddress, which only the SDK uses; accounts holding both legal types must also send customerType.
The sell example reused the buy quote, so registerRamp dispatched it to the onramp handler, and it indexed an empty account list for sellers who had not added a pay-out account.
listDomesticFiatAccounts takes the exported DomesticCountry string enum, so the "MX" literal fails TypeScript type-checking.
…own-account Document the dashboard route to API keys and an own-account ramp path
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
1 participant
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.
No description provided.