# durable-objects
- j
john.spurlock
05/09/2023, 9:56 PMoh like you just saw it once with no functional outage? I'm seeing all callers into the DO in question fail with internal error/etc for about 15/20 minutes now - j
john.spurlock
05/09/2023, 9:56 PMhard to tell, my logs aren't exactly realtime - d
Dani Foldi
05/09/2023, 9:56 PMyeah, although you probably do as many DO requests in a second as we had yesterday 😅 - j
john.spurlock
05/09/2023, 9:59 PMfortunately not a very busy time, handling about 2.5k req/5m -> 8.3 req/s - d
Dani Foldi
05/09/2023, 9:59 PM@ckoeninger - j
john.spurlock
05/09/2023, 10:06 PMthanks all, looks like it's back in business, from what I can tell, still in DFW so whatever was happening was maybe machine specifichttps://cdn.discordapp.com/attachments/773219443911819284/1105616759672799242/image.pngâ–¾
- s
sathoro
05/10/2023, 8:09 AMhow to get more visibility on what the errors are for my DO?https://cdn.discordapp.com/attachments/773219443911819284/1105768443476717629/image.pngâ–¾
- s
sathoro
05/10/2023, 8:09 AMthese are likely happening within an alarm btw - s
sathoro
05/10/2023, 8:27 AMoh boy, I think we are running into the DO storage value size limit 😦 we have a task queue and store each task as their own value and they can get quite large - s
sathoro
05/10/2023, 8:29 AMwe can at least delete the checkpoint values when saving the final full output on the last step so that will need to be good enough for now - s
sathoro
05/10/2023, 8:31 AMone thing I could use help with though is how this error didn't get caught in Sentry. we catch all exceptions but this didn't get caught. does it throw an error or is the DO just killed? - s
sathoro
05/10/2023, 8:56 AMdid some testing, and it does seem to throw an error.
. time to figure out how this was not caught in our codeRangeError: Values cannot be larger than 131072 bytes. - s
sathoro
05/10/2023, 8:59 AMmissing an
keyword, lovelyawait - c
Crazy Rabbit
05/10/2023, 11:19 AMWelcome to JavaScript - s
sathoro
05/10/2023, 4:52 PMI have found it particularly confusing when using DOs when to await and not. because with storage operations you don't usually need to await (since it will not kill the DO until the op is complete) but in this case it bit me - u
Unsmart | Tech debt
05/10/2023, 4:55 PMI personally always await ops before returning to the user 🤷 - d
Dani Foldi
05/10/2023, 4:57 PMWebStorm complains if I leave Promises unawaited - s
sathoro
05/10/2023, 6:55 PMthis was in an alarm - u
Unsmart | Tech debt
05/10/2023, 6:56 PMin that case before you return the all good to the alarm 😅 - s
sathoro
05/10/2023, 6:57 PMsame concept I know but we do a lot of stuff in the alarm so I think I was trying to cut down a bit on operations. especially if we do a storage op right before a long IO then waiting seemed unneeded - s
sathoro
05/10/2023, 6:57 PMbut yeah dumb optimization - h
hanpolo
05/10/2023, 9:07 PMAre there articles or any thoughts on how to secure durable objects? For example through tokens, or can they be firewalled so they only talk to specific domains etc. - h
HardAtWork
05/10/2023, 9:32 PMI mean, you can’t access DO directly, so any authentication can be handled in your Worker - h
hanpolo
05/10/2023, 9:41 PMSo what's to stop someone else writing a worker, getting hold of the DO Id and just calling it? - h
hanpolo
05/10/2023, 9:42 PMIs there some sort of rule that says only workers within the same project can call the DO? - k
kian
05/10/2023, 9:42 PMThat’s not quite how DOs work - k
kian
05/10/2023, 9:42 PMIf it isn’t bound to your Worker then it can’t be called - k
kian
05/10/2023, 9:42 PMIts not an externally facing thing - h
hanpolo
05/10/2023, 9:42 PMOk .. what if I'm calling it from a function in my Pages project? Same deal? - s
Skye
05/10/2023, 9:44 PMIt's bound to your account, only your scripts can access it