Bug Report Checklist
Description
I'm working on an application which has multiple API requests that fire at the same time, especially when triggered from a TaskGroup to happen simultanously. Each request attempts to do token refresh if appropriate, meaning they could – in theory – end up writing at the exact same time to the open class <GeneratedName>API class's static customHeaders property.
While I have serialised the code I've written to access the customHeaders property, I'm still getting some crashes in our Firebase from where OpenAPI Generator internals are accessing that property – presumably at the same time it's being written to.
openapi-generator version
7.1, but this has existed at least as long as openapi-generator has supported async/await.
Steps to reproduce
Use a TaskGroup that sometimes simultaneously write to the generated <GeneratedName>API.customHeaders property. Sometimes (but not always, given this is a data race) this will cause a memory corruption error and crash the application.
Suggest a fix
If it was at all possible to completely isolate these properties using an actor, I believe that would be the most ideal solution. Failing that, using some sort of lock – or at least serialising access via a queue – would probably help.
Bug Report Checklist
Description
I'm working on an application which has multiple API requests that fire at the same time, especially when triggered from a
TaskGroupto happen simultanously. Each request attempts to do token refresh if appropriate, meaning they could – in theory – end up writing at the exact same time to theopen class <GeneratedName>APIclass's staticcustomHeadersproperty.While I have serialised the code I've written to access the
customHeadersproperty, I'm still getting some crashes in our Firebase from where OpenAPI Generator internals are accessing that property – presumably at the same time it's being written to.openapi-generator version
7.1, but this has existed at least as long as openapi-generator has supported
async/await.Steps to reproduce
Use a
TaskGroupthat sometimes simultaneously write to the generated<GeneratedName>API.customHeadersproperty. Sometimes (but not always, given this is a data race) this will cause a memory corruption error and crash the application.Suggest a fix
If it was at all possible to completely isolate these properties using an
actor, I believe that would be the most ideal solution. Failing that, using some sort of lock – or at least serialising access via a queue – would probably help.