You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm looking to establish if this qualifies as a bug or is intentional -- when I am using the cache service and some condition in my input makes me want to "abort" caching the thing (e.g., a network request failure) I'm not sure how to do that.
The cache service first tries to set data from the input:
If input() throws an exception data does not get set. When the cache service catches this exception, it reports and the error and then tries to run input() again, causing the same exception to be thrown:
logger?.error(`[Cache] Error SET '${cacheKey}': ${e.message}`)
returnserialize(data||(awaitinput()))
}
If I put the cache call in my own try ... catch, I can catch and handle the exception and that is kind of helpful. But since input is run twice, there is also a chance that the first run causes an exception and the second run does not so I may get confusing error reporting or miss intermittent issues entirely.
A pattern I have used and liked in other cache interfaces is the ability to throw some specific exception type that tells the cache system to not cache a result (e.g. throw new UncacheableError()) without throwing it's own exception.
Alternatively, I think it would be possible to just return undefined from the catch statement in cache.
If this really is the desired behavior, I think it would be helpful to add some documentation around cache service error handling.
How do we reproduce the bug?
awaitcache(['key'],()=>{thrownewError('Something went wrong!')})
What's your environment? (If it applies)
Are you interested in working on this?
I'm interested in working on this
The text was updated successfully, but these errors were encountered:
What's not working?
I'm looking to establish if this qualifies as a bug or is intentional -- when I am using the
cache
service and some condition in my input makes me want to "abort" caching the thing (e.g., a network request failure) I'm not sure how to do that.The cache service first tries to set
data
from the input:redwood/packages/api/src/cache/index.ts
Line 118 in 6bbb925
If
input()
throws an exceptiondata
does not get set. When thecache
service catches this exception, it reports and the error and then tries to runinput()
again, causing the same exception to be thrown:redwood/packages/api/src/cache/index.ts
Lines 131 to 134 in 6bbb925
If I put the
cache
call in my owntry ... catch
, I can catch and handle the exception and that is kind of helpful. But sinceinput
is run twice, there is also a chance that the first run causes an exception and the second run does not so I may get confusing error reporting or miss intermittent issues entirely.A pattern I have used and liked in other cache interfaces is the ability to throw some specific exception type that tells the cache system to not cache a result (e.g.
throw new UncacheableError()
) without throwing it's own exception.Alternatively, I think it would be possible to just return
undefined
from thecatch
statement incache
.If this really is the desired behavior, I think it would be helpful to add some documentation around cache service error handling.
How do we reproduce the bug?
What's your environment? (If it applies)
Are you interested in working on this?
The text was updated successfully, but these errors were encountered: