No, but if you use SQL, the KV APIs still work, same api, and just use a hidden table
No, but if you use SQL, the KV APIs still work, same api, and just use a hidden table
isolatedStorage option, which IIRC is on by default.fetch
user_ids and get a stub for each string, and read some data, and collect it together, but want to try and speed that process up as much as possibleconst ran = await runDurableObjectAlarm(stub); expect(ran).toBe(true);// expects true but is falsethis.state.getWebSockets on each stub, is this 1 DO request per stub? Do these count toward the subrequest limit of the initially invoked Worker?
user_idconst ran = await runDurableObjectAlarm(stub); expect(ran).toBe(true); it("adds jobs and schedules an alarm", async () => {
const result = await runInDurableObject(stub, async (instance, state) => {
return await instance.addJobs([
{ url: "https://example.com" },
{ url: "https://example.org" },
]);
});
expect(result).toBe("Jobs added");
// Run the alarm (which calls processQueue & processTimeouts)
const ran = await runDurableObjectAlarm(stub);
expect(ran).toBe(true);
const status = await runInDurableObject(stub, async (instance) => {
return await instance.getStatus();
});
expect(status).toEqual([{ status: "pending", count: 2 }]);
});Durable Object alarms are not reset between test runs and do not respect isolated storage. Ensure you delete or run all alarms with runDurableObjectAlarm() scheduled in each test before finishing the test. afterEach(async () => {
// Clear any pending alarms between tests.
await runInDurableObject(stub, async (_instance, state) => {
await state.storage.deleteAlarm();
});
vi.restoreAllMocks();
});this.state.getWebSockets