[ otelgorm ] shortcomings while handling SAVEPOINT operations

[mahfooz-fpay]

The library is great at handling user initiated operatioins and make a proper trace tree out of it ! We at famApp use it for implementing distributed tracing for our API exposed server to track db operation performances.
Shortcoming :
Situation : Even if you don't explicitly nest transactions, GORM might use savepoints to emulate nested transactions. If GORM encounters certain constructs that resemble nested transactions, it can create savepoints to ensure the atomicity of parts of the transaction.
otelgorm Behaviour : Db initiated calls are being treated as independent transactions and is not linked to the previous spans and hence been allocated new traceID id . This breaks the flow leading to "missing span instrumentation" errors when the traces are being sent to sentry because the SAVEPOINT had a different trace-id and hence was not linked with the parent traceID.
Desired Behaviour : The middleware should keep track of the db initiated savepoints operations and create child span from the span stored in the previous context rather than passing a new context and allocating a new traceID.

[ The missing instrumentation you see was supposed to be filled by SAVEPOINT opearation ]

*Note : My operation didn't contained any savepoint queries, it was a default db behaviour.