Ensure abortSignal is threaded through to reconnect fetch calls

[gsathya]

Summary

This PR fixes abort handling in WorkflowChatTransport reconnect flows. Fixes#1186

Previously, the caller’s abortSignal was passed to the initial chat POST request, but not to reconnect GET requests (/stream?startIndex=...). That meant a client abort could stop the first request while a reconnect fetch continued running. This PR threads the same signal through reconnect fetches and the reconnect stream wrapper so abort behavior is consistent across both entry points.

What changed

• reconnectToStreamIterator(...) now passes signal: options.abortSignal to reconnect fetch(...) calls.
• reconnectToStream(...) now passes options.abortSignal into iteratorToStream(...), matching sendMessages(...).
• ReconnectToStreamOptions now includes an optional abortSignal?: AbortSignal.

Scope

• Small public type change (backward-compatible): exported ReconnectToStreamOptions now includes optional abortSignal?: AbortSignal.
• No changes to reconnect URL construction, request customization hooks, or retry logic (other than fetches now being abortable as intended).

Test coverage

• Updated existing reconnect request test to include signal: undefined in the expected fetch options when no abort signal is provided.
• Added regression test that reconnectToStream({ abortSignal }) forwards the exact signal to the reconnect fetch.
• Added regression test that sendMessages({ abortSignal }) reuses the same signal for both:
  • the initial POST fetch
  • the reconnect GET fetch after an interrupted/unfinished initial stream

Validation

• pnpm --filter @workflow/ai build ✅
• pnpm vitest packages/ai/src/workflow-chat-transport.test.ts ✅ (12/12 passing)

[changeset-bot]

🦋 Changeset detected

Latest commit: 9f7d367

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@workflow/ai	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

@gsathya is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

Additional Suggestion:

TypeScript compilation error: options.abortSignal is accessed in reconnectToStream and reconnectToStreamIterator but abortSignal is not defined on the ReconnectToStreamOptions interface or ChatRequestOptions type.

[gsathya]

i'm currently working around this in prod with a custom fetch that respects the abort signal:

fetch: (input,init)=>{constunmountSignal=abortControllerRef.current.signal;constsignal=init?.signal
? AbortSignal.any([init.signal,unmountSignal])
: unmountSignal;returnfetch(input,{ ...init, signal });},

but i'd prefer to use the builtin one and not have custom code, is there anything i can do push this through?

cc @pranaygp

[VaguelySerious]

Hi @gsathya, this looks good to me, thanks for contributing. Could you:

• Add a changeset (pnpm changeset) for a patch version on @workflow/ai
• Ensure DCO passes (see instructions)

so that we can get this shipped?

[gsathya]

Hi @gsathya, this looks good to me, thanks for contributing. Could you:

• Add a changeset (pnpm changeset) for a patch version on @workflow/ai
• Ensure DCO passes (see instructions)

so that we can get this shipped?

Thanks @VaguelySerious! I've updated the pr with the changes

[gsathya]

Summary

This PR fixes abort handling in WorkflowChatTransport reconnect flows. Fixes#1186

Previously, the caller’s abortSignal was passed to the initial chat POST request, but not to reconnect GET requests (/stream?startIndex=...). That meant a client abort could stop the first request while a reconnect fetch continued running. This PR threads the same signal through reconnect fetches and the reconnect stream wrapper so abort behavior is consistent across both entry points.

What changed

• reconnectToStreamIterator(...) now passes signal: options.abortSignal to reconnect fetch(...) calls.
• reconnectToStream(...) now passes options.abortSignal into iteratorToStream(...), matching sendMessages(...).
• ReconnectToStreamOptions now includes an optional abortSignal?: AbortSignal.

Scope

• Small public type change (backward-compatible): exported ReconnectToStreamOptions now includes optional abortSignal?: AbortSignal.
• No changes to reconnect URL construction, request customization hooks, or retry logic (other than fetches now being abortable as intended).

Test coverage

• Updated existing reconnect request test to include signal: undefined in the expected fetch options when no abort signal is provided.
• Added regression test that reconnectToStream({ abortSignal }) forwards the exact signal to the reconnect fetch.
• Added regression test that sendMessages({ abortSignal }) reuses the same signal for both:
  • the initial POST fetch
  • the reconnect GET fetch after an interrupted/unfinished initial stream

Validation

• pnpm --filter @workflow/ai build ✅
• pnpm vitest packages/ai/src/workflow-chat-transport.test.ts ✅ (12/12 passing)

[changeset-bot]

🦋 Changeset detected

Latest commit: 9f7d367

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@workflow/ai	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

@gsathya is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

Additional Suggestion:

TypeScript compilation error: options.abortSignal is accessed in reconnectToStream and reconnectToStreamIterator but abortSignal is not defined on the ReconnectToStreamOptions interface or ChatRequestOptions type.

[gsathya]

i'm currently working around this in prod with a custom fetch that respects the abort signal:

fetch: (input,init)=>{constunmountSignal=abortControllerRef.current.signal;constsignal=init?.signal
? AbortSignal.any([init.signal,unmountSignal])
: unmountSignal;returnfetch(input,{ ...init, signal });},

but i'd prefer to use the builtin one and not have custom code, is there anything i can do push this through?

cc @pranaygp

[VaguelySerious]

Hi @gsathya, this looks good to me, thanks for contributing. Could you:

• Add a changeset (pnpm changeset) for a patch version on @workflow/ai
• Ensure DCO passes (see instructions)

so that we can get this shipped?

[gsathya]

Hi @gsathya, this looks good to me, thanks for contributing. Could you:

• Add a changeset (pnpm changeset) for a patch version on @workflow/ai
• Ensure DCO passes (see instructions)

so that we can get this shipped?

Thanks @VaguelySerious! I've updated the pr with the changes

[gsathya]

Summary

This PR fixes abort handling in WorkflowChatTransport reconnect flows. Fixes#1186

Previously, the caller’s abortSignal was passed to the initial chat POST request, but not to reconnect GET requests (/stream?startIndex=...). That meant a client abort could stop the first request while a reconnect fetch continued running. This PR threads the same signal through reconnect fetches and the reconnect stream wrapper so abort behavior is consistent across both entry points.

What changed

• reconnectToStreamIterator(...) now passes signal: options.abortSignal to reconnect fetch(...) calls.
• reconnectToStream(...) now passes options.abortSignal into iteratorToStream(...), matching sendMessages(...).
• ReconnectToStreamOptions now includes an optional abortSignal?: AbortSignal.

Scope

• Small public type change (backward-compatible): exported ReconnectToStreamOptions now includes optional abortSignal?: AbortSignal.
• No changes to reconnect URL construction, request customization hooks, or retry logic (other than fetches now being abortable as intended).

Test coverage

• Updated existing reconnect request test to include signal: undefined in the expected fetch options when no abort signal is provided.
• Added regression test that reconnectToStream({ abortSignal }) forwards the exact signal to the reconnect fetch.
• Added regression test that sendMessages({ abortSignal }) reuses the same signal for both:
  • the initial POST fetch
  • the reconnect GET fetch after an interrupted/unfinished initial stream

Validation

• pnpm --filter @workflow/ai build ✅
• pnpm vitest packages/ai/src/workflow-chat-transport.test.ts ✅ (12/12 passing)

[changeset-bot]

🦋 Changeset detected

Latest commit: 9f7d367

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@workflow/ai	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

@gsathya is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

Additional Suggestion:

TypeScript compilation error: options.abortSignal is accessed in reconnectToStream and reconnectToStreamIterator but abortSignal is not defined on the ReconnectToStreamOptions interface or ChatRequestOptions type.

[gsathya]

i'm currently working around this in prod with a custom fetch that respects the abort signal:

fetch: (input,init)=>{constunmountSignal=abortControllerRef.current.signal;constsignal=init?.signal
? AbortSignal.any([init.signal,unmountSignal])
: unmountSignal;returnfetch(input,{ ...init, signal });},

but i'd prefer to use the builtin one and not have custom code, is there anything i can do push this through?

cc @pranaygp

[VaguelySerious]

Hi @gsathya, this looks good to me, thanks for contributing. Could you:

• Add a changeset (pnpm changeset) for a patch version on @workflow/ai
• Ensure DCO passes (see instructions)

so that we can get this shipped?

[gsathya]

Hi @gsathya, this looks good to me, thanks for contributing. Could you:

• Add a changeset (pnpm changeset) for a patch version on @workflow/ai
• Ensure DCO passes (see instructions)

so that we can get this shipped?

Thanks @VaguelySerious! I've updated the pr with the changes

[gsathya]

Summary

This PR fixes abort handling in WorkflowChatTransport reconnect flows. Fixes#1186

Previously, the caller’s abortSignal was passed to the initial chat POST request, but not to reconnect GET requests (/stream?startIndex=...). That meant a client abort could stop the first request while a reconnect fetch continued running. This PR threads the same signal through reconnect fetches and the reconnect stream wrapper so abort behavior is consistent across both entry points.

What changed

• reconnectToStreamIterator(...) now passes signal: options.abortSignal to reconnect fetch(...) calls.
• reconnectToStream(...) now passes options.abortSignal into iteratorToStream(...), matching sendMessages(...).
• ReconnectToStreamOptions now includes an optional abortSignal?: AbortSignal.

Scope

• Small public type change (backward-compatible): exported ReconnectToStreamOptions now includes optional abortSignal?: AbortSignal.
• No changes to reconnect URL construction, request customization hooks, or retry logic (other than fetches now being abortable as intended).

Test coverage

• Updated existing reconnect request test to include signal: undefined in the expected fetch options when no abort signal is provided.
• Added regression test that reconnectToStream({ abortSignal }) forwards the exact signal to the reconnect fetch.
• Added regression test that sendMessages({ abortSignal }) reuses the same signal for both:
  • the initial POST fetch
  • the reconnect GET fetch after an interrupted/unfinished initial stream

Validation

• pnpm --filter @workflow/ai build ✅
• pnpm vitest packages/ai/src/workflow-chat-transport.test.ts ✅ (12/12 passing)

[changeset-bot]

🦋 Changeset detected

Latest commit: 9f7d367

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@workflow/ai	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

@gsathya is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

Additional Suggestion:

TypeScript compilation error: options.abortSignal is accessed in reconnectToStream and reconnectToStreamIterator but abortSignal is not defined on the ReconnectToStreamOptions interface or ChatRequestOptions type.

[gsathya]

i'm currently working around this in prod with a custom fetch that respects the abort signal:

fetch: (input,init)=>{constunmountSignal=abortControllerRef.current.signal;constsignal=init?.signal
? AbortSignal.any([init.signal,unmountSignal])
: unmountSignal;returnfetch(input,{ ...init, signal });},

but i'd prefer to use the builtin one and not have custom code, is there anything i can do push this through?

cc @pranaygp

[VaguelySerious]

Hi @gsathya, this looks good to me, thanks for contributing. Could you:

• Add a changeset (pnpm changeset) for a patch version on @workflow/ai
• Ensure DCO passes (see instructions)

so that we can get this shipped?

[gsathya]

Hi @gsathya, this looks good to me, thanks for contributing. Could you:

• Add a changeset (pnpm changeset) for a patch version on @workflow/ai
• Ensure DCO passes (see instructions)

so that we can get this shipped?

Thanks @VaguelySerious! I've updated the pr with the changes

[gsathya]

Summary

This PR fixes abort handling in WorkflowChatTransport reconnect flows. Fixes#1186

Previously, the caller’s abortSignal was passed to the initial chat POST request, but not to reconnect GET requests (/stream?startIndex=...). That meant a client abort could stop the first request while a reconnect fetch continued running. This PR threads the same signal through reconnect fetches and the reconnect stream wrapper so abort behavior is consistent across both entry points.

What changed

• reconnectToStreamIterator(...) now passes signal: options.abortSignal to reconnect fetch(...) calls.
• reconnectToStream(...) now passes options.abortSignal into iteratorToStream(...), matching sendMessages(...).
• ReconnectToStreamOptions now includes an optional abortSignal?: AbortSignal.

Scope

• Small public type change (backward-compatible): exported ReconnectToStreamOptions now includes optional abortSignal?: AbortSignal.
• No changes to reconnect URL construction, request customization hooks, or retry logic (other than fetches now being abortable as intended).

Test coverage

• Updated existing reconnect request test to include signal: undefined in the expected fetch options when no abort signal is provided.
• Added regression test that reconnectToStream({ abortSignal }) forwards the exact signal to the reconnect fetch.
• Added regression test that sendMessages({ abortSignal }) reuses the same signal for both:
  • the initial POST fetch
  • the reconnect GET fetch after an interrupted/unfinished initial stream

Validation

• pnpm --filter @workflow/ai build ✅
• pnpm vitest packages/ai/src/workflow-chat-transport.test.ts ✅ (12/12 passing)

[changeset-bot]

🦋 Changeset detected

Latest commit: 9f7d367

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@workflow/ai	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

@gsathya is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

Additional Suggestion:

TypeScript compilation error: options.abortSignal is accessed in reconnectToStream and reconnectToStreamIterator but abortSignal is not defined on the ReconnectToStreamOptions interface or ChatRequestOptions type.

[gsathya]

i'm currently working around this in prod with a custom fetch that respects the abort signal:

fetch: (input,init)=>{constunmountSignal=abortControllerRef.current.signal;constsignal=init?.signal
? AbortSignal.any([init.signal,unmountSignal])
: unmountSignal;returnfetch(input,{ ...init, signal });},

but i'd prefer to use the builtin one and not have custom code, is there anything i can do push this through?

cc @pranaygp

[VaguelySerious]

Hi @gsathya, this looks good to me, thanks for contributing. Could you:

• Add a changeset (pnpm changeset) for a patch version on @workflow/ai
• Ensure DCO passes (see instructions)

so that we can get this shipped?

[gsathya]

Hi @gsathya, this looks good to me, thanks for contributing. Could you:

• Add a changeset (pnpm changeset) for a patch version on @workflow/ai
• Ensure DCO passes (see instructions)

so that we can get this shipped?

Thanks @VaguelySerious! I've updated the pr with the changes

[gsathya]

Summary

This PR fixes abort handling in WorkflowChatTransport reconnect flows. Fixes#1186

Previously, the caller’s abortSignal was passed to the initial chat POST request, but not to reconnect GET requests (/stream?startIndex=...). That meant a client abort could stop the first request while a reconnect fetch continued running. This PR threads the same signal through reconnect fetches and the reconnect stream wrapper so abort behavior is consistent across both entry points.

What changed

• reconnectToStreamIterator(...) now passes signal: options.abortSignal to reconnect fetch(...) calls.
• reconnectToStream(...) now passes options.abortSignal into iteratorToStream(...), matching sendMessages(...).
• ReconnectToStreamOptions now includes an optional abortSignal?: AbortSignal.

Scope

• Small public type change (backward-compatible): exported ReconnectToStreamOptions now includes optional abortSignal?: AbortSignal.
• No changes to reconnect URL construction, request customization hooks, or retry logic (other than fetches now being abortable as intended).

Test coverage

• Updated existing reconnect request test to include signal: undefined in the expected fetch options when no abort signal is provided.
• Added regression test that reconnectToStream({ abortSignal }) forwards the exact signal to the reconnect fetch.
• Added regression test that sendMessages({ abortSignal }) reuses the same signal for both:
  • the initial POST fetch
  • the reconnect GET fetch after an interrupted/unfinished initial stream

Validation

• pnpm --filter @workflow/ai build ✅
• pnpm vitest packages/ai/src/workflow-chat-transport.test.ts ✅ (12/12 passing)

[changeset-bot]

🦋 Changeset detected

Latest commit: 9f7d367

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@workflow/ai	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

@gsathya is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

Additional Suggestion:

TypeScript compilation error: options.abortSignal is accessed in reconnectToStream and reconnectToStreamIterator but abortSignal is not defined on the ReconnectToStreamOptions interface or ChatRequestOptions type.

[gsathya]

i'm currently working around this in prod with a custom fetch that respects the abort signal:

fetch: (input,init)=>{constunmountSignal=abortControllerRef.current.signal;constsignal=init?.signal
? AbortSignal.any([init.signal,unmountSignal])
: unmountSignal;returnfetch(input,{ ...init, signal });},

but i'd prefer to use the builtin one and not have custom code, is there anything i can do push this through?

cc @pranaygp

[VaguelySerious]

Hi @gsathya, this looks good to me, thanks for contributing. Could you:

• Add a changeset (pnpm changeset) for a patch version on @workflow/ai
• Ensure DCO passes (see instructions)

so that we can get this shipped?

[gsathya]

Hi @gsathya, this looks good to me, thanks for contributing. Could you:

• Add a changeset (pnpm changeset) for a patch version on @workflow/ai
• Ensure DCO passes (see instructions)

so that we can get this shipped?

Thanks @VaguelySerious! I've updated the pr with the changes

[gsathya]

Summary

This PR fixes abort handling in WorkflowChatTransport reconnect flows. Fixes#1186

Previously, the caller’s abortSignal was passed to the initial chat POST request, but not to reconnect GET requests (/stream?startIndex=...). That meant a client abort could stop the first request while a reconnect fetch continued running. This PR threads the same signal through reconnect fetches and the reconnect stream wrapper so abort behavior is consistent across both entry points.

What changed

• reconnectToStreamIterator(...) now passes signal: options.abortSignal to reconnect fetch(...) calls.
• reconnectToStream(...) now passes options.abortSignal into iteratorToStream(...), matching sendMessages(...).
• ReconnectToStreamOptions now includes an optional abortSignal?: AbortSignal.

Scope

• Small public type change (backward-compatible): exported ReconnectToStreamOptions now includes optional abortSignal?: AbortSignal.
• No changes to reconnect URL construction, request customization hooks, or retry logic (other than fetches now being abortable as intended).

Test coverage

• Updated existing reconnect request test to include signal: undefined in the expected fetch options when no abort signal is provided.
• Added regression test that reconnectToStream({ abortSignal }) forwards the exact signal to the reconnect fetch.
• Added regression test that sendMessages({ abortSignal }) reuses the same signal for both:
  • the initial POST fetch
  • the reconnect GET fetch after an interrupted/unfinished initial stream

Validation

• pnpm --filter @workflow/ai build ✅
• pnpm vitest packages/ai/src/workflow-chat-transport.test.ts ✅ (12/12 passing)

[changeset-bot]

🦋 Changeset detected

Latest commit: 9f7d367

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@workflow/ai	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

@gsathya is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

Additional Suggestion:

TypeScript compilation error: options.abortSignal is accessed in reconnectToStream and reconnectToStreamIterator but abortSignal is not defined on the ReconnectToStreamOptions interface or ChatRequestOptions type.

[gsathya]

i'm currently working around this in prod with a custom fetch that respects the abort signal:

fetch: (input,init)=>{constunmountSignal=abortControllerRef.current.signal;constsignal=init?.signal
? AbortSignal.any([init.signal,unmountSignal])
: unmountSignal;returnfetch(input,{ ...init, signal });},

but i'd prefer to use the builtin one and not have custom code, is there anything i can do push this through?

cc @pranaygp

[VaguelySerious]

Hi @gsathya, this looks good to me, thanks for contributing. Could you:

• Add a changeset (pnpm changeset) for a patch version on @workflow/ai
• Ensure DCO passes (see instructions)

so that we can get this shipped?

[gsathya]

Hi @gsathya, this looks good to me, thanks for contributing. Could you:

• Add a changeset (pnpm changeset) for a patch version on @workflow/ai
• Ensure DCO passes (see instructions)

so that we can get this shipped?

Thanks @VaguelySerious! I've updated the pr with the changes

[gsathya]

Summary

This PR fixes abort handling in WorkflowChatTransport reconnect flows. Fixes#1186

Previously, the caller’s abortSignal was passed to the initial chat POST request, but not to reconnect GET requests (/stream?startIndex=...). That meant a client abort could stop the first request while a reconnect fetch continued running. This PR threads the same signal through reconnect fetches and the reconnect stream wrapper so abort behavior is consistent across both entry points.

What changed

• reconnectToStreamIterator(...) now passes signal: options.abortSignal to reconnect fetch(...) calls.
• reconnectToStream(...) now passes options.abortSignal into iteratorToStream(...), matching sendMessages(...).
• ReconnectToStreamOptions now includes an optional abortSignal?: AbortSignal.

Scope

• Small public type change (backward-compatible): exported ReconnectToStreamOptions now includes optional abortSignal?: AbortSignal.
• No changes to reconnect URL construction, request customization hooks, or retry logic (other than fetches now being abortable as intended).

Test coverage

• Updated existing reconnect request test to include signal: undefined in the expected fetch options when no abort signal is provided.
• Added regression test that reconnectToStream({ abortSignal }) forwards the exact signal to the reconnect fetch.
• Added regression test that sendMessages({ abortSignal }) reuses the same signal for both:
  • the initial POST fetch
  • the reconnect GET fetch after an interrupted/unfinished initial stream

Validation

• pnpm --filter @workflow/ai build ✅
• pnpm vitest packages/ai/src/workflow-chat-transport.test.ts ✅ (12/12 passing)

[changeset-bot]

🦋 Changeset detected

Latest commit: 9f7d367

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@workflow/ai	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

@gsathya is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

Additional Suggestion:

TypeScript compilation error: options.abortSignal is accessed in reconnectToStream and reconnectToStreamIterator but abortSignal is not defined on the ReconnectToStreamOptions interface or ChatRequestOptions type.

[gsathya]

i'm currently working around this in prod with a custom fetch that respects the abort signal:

fetch: (input,init)=>{constunmountSignal=abortControllerRef.current.signal;constsignal=init?.signal
? AbortSignal.any([init.signal,unmountSignal])
: unmountSignal;returnfetch(input,{ ...init, signal });},

but i'd prefer to use the builtin one and not have custom code, is there anything i can do push this through?

cc @pranaygp

[VaguelySerious]

Hi @gsathya, this looks good to me, thanks for contributing. Could you:

• Add a changeset (pnpm changeset) for a patch version on @workflow/ai
• Ensure DCO passes (see instructions)

so that we can get this shipped?

[gsathya]

Hi @gsathya, this looks good to me, thanks for contributing. Could you:

• Add a changeset (pnpm changeset) for a patch version on @workflow/ai
• Ensure DCO passes (see instructions)

so that we can get this shipped?

Thanks @VaguelySerious! I've updated the pr with the changes