-
Notifications
You must be signed in to change notification settings - Fork 314
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add optional AlarmInvocationInfo parameter to Durable Object alarm() method #3224
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -467,7 +467,7 @@ interface Cloudflare { | |
} | ||
interface DurableObject { | ||
fetch(request: Request): Response | Promise<Response>; | ||
alarm?(): void | Promise<void>; | ||
alarm?(alarmInfo?: AlarmInvocationInfo): void | Promise<void>; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The changes to
I assume it's doing the right thing by regenerating these snapshot files, but I'm not familiar with the intent. |
||
webSocketMessage?( | ||
ws: WebSocket, | ||
message: string | ArrayBuffer, | ||
|
@@ -5312,7 +5312,7 @@ declare module "cloudflare:workers" { | |
protected env: Env; | ||
constructor(ctx: DurableObjectState, env: Env); | ||
fetch?(request: Request): Response | Promise<Response>; | ||
alarm?(): void | Promise<void>; | ||
alarm?(alarmInfo?: AlarmInvocationInfo): void | Promise<void>; | ||
webSocketMessage?( | ||
ws: WebSocket, | ||
message: string | ArrayBuffer, | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -306,6 +306,27 @@ class TestObject extends DurableObject { | |
} | ||
} | ||
|
||
class TestAlarmObject extends DurableObject { | ||
// Can declare alarm method consuming optional alarmInfo parameter | ||
async alarm(alarmInfo?: AlarmInvocationInfo) { | ||
if (alarmInfo !== undefined) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. FWIW, the current version of the runtime always passes this I'm not sure if there is a better way to declare the method in the TS Probably not a big deal in the common case, though, since most implementers probably won't be writing an There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Dumb question: is there a way to set the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not dumb -- I was wondering myself, but am not familiar with how we are doing versioning and backwards compatibility of TypeScript declarations. I assume the purpose of the various I suspect this feature will be infrequently used enough that it might not be worth breaking backwards compatibility for, by itself -- but if there comes a time when we're breaking backwards compatibility anyway, that might be a convenient time to make the parameter mandatory? |
||
const _isRetry: boolean = alarmInfo.isRetry; | ||
const _retryCount: number = alarmInfo.retryCount; | ||
} | ||
} | ||
|
||
// User code can invoke alarm() directly, if desired. | ||
async runAlarmVoid(): Promise<void> { | ||
return await this.alarm(); | ||
} | ||
async runAlarmInfo(): Promise<void> { | ||
return await this.alarm({ | ||
isRetry: true, | ||
retryCount: 1, | ||
}); | ||
} | ||
} | ||
|
||
class TestNaughtyEntrypoint extends WorkerEntrypoint { | ||
// Check incorrectly typed methods | ||
// @ts-expect-error | ||
|
@@ -351,6 +372,7 @@ interface Env { | |
|
||
REGULAR_OBJECT: DurableObjectNamespace; | ||
RPC_OBJECT: DurableObjectNamespace<TestObject>; | ||
ALARM_OBJECT: DurableObjectNamespace<TestAlarmObject>; | ||
NAUGHTY_OBJECT: DurableObjectNamespace<TestNaughtyObject>; | ||
// @ts-expect-error `BoringClass` isn't an RPC capable type | ||
__INVALID_OBJECT_1: DurableObjectNamespace<BoringClass>; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I notice in our
index.d.ts
files, we define both aDurableObject
interface at the top level and aDurableObject
abstract class inside thecloudflare:workers
module. I think the interface is intended to cover legacy uses of Durable Objects prior to the introduction of the class, and that extending the class is the way we recommend implementing Durable Objects in documentation and tutorials. I'm not sure whether it's important to add the parameter to the interface, or where that gets tested, but I went ahead and added it for completeness.