Repository navigation
Unreleased semaphore blocks httprc indefinitely if a Transform panics #33
Description
Activity
- changed the title
[-]Unreleased semaphore can block httprc if a Transform panics[/-][+]Unreleased semaphore blocks httprc indefinitely if a Transform panics[/+]on Sep 22, 2024 I've open #33 which should fix the issue
IIRC, that
releaseSemis intentional: I wanted it to be released BEFORE the next lock happened in the same function happened, not when the function returned. I think if a Transoform could panic it would be better to protect the call to Transform itself, not the locks.I think it's troublesome that a
Transformcould block the cacheSince a
Transformis intended to do things like parsing XML, RSS, and it can happen for one of those to panicWe run this lib in a REST/GQL service and I as a client did not expect that panic would block my GQL resolvers/REST handlers :D
I've already protected my
Transformfunction, but I still think this behaviour should not be expected
At the very least could we add a note in the README?No, I'm not arguing against putting a fix, but I'm suggesting that you could protect the call to
e.transform.TransforminfetchAndStoreinstead of mucking with the locks.(As an side: I don't disagree with needing to handle error cases like this, but TBH if you have the leeway to do so, I'd reconsider using RSS/XML libraries that panic instead of returning errors)
Ah, I misunderstood, I'll try to give it a go this weekend on protecting the
Transformcall itself (.transform.Transform) and leaving the semaphore alone
Description
The semaphore acquired here
httprc/cache.go
Line 155 in e71784b
deferIf a
Transformpanics the semaphore is never released, and the next call to aCache.Getwill block indefinitely