Closed alovak closed 1 year ago
Attention: 11 lines
in your changes are missing coverage. Please review.
Comparison is base (
b652df4
) 73.70% compared to head (d2157a7
) 73.95%.:exclamation: Current head d2157a7 differs from pull request most recent head a0dcd00. Consider uploading reports for the commit a0dcd00 to get more accurate results
:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
With this PR, we've enhanced the concurrency safety of the methods in
iso8583.Message
andfield.Composite
.Rationale
I encountered a data race when two goroutines executed
message.GetString(11)
. This happened because the GetString method did more than just returning a value — it also updated an internal map. This concurrent access led to the race condition.Assumptions on Concurrency:
field.String
,field.Numeric
) is not thread-safe. Concurrency safety is ensured at theMessage
andComposite
levels. If external concurrent access to individual fields is necessary, users should manage it with appropriate synchronization mechanisms, such as a mutex.Concerns
A potential solution to the data race I encountered would have been to simply eliminate the unnecessary map modification, thus making
GetXXX()
methods pure getters (which is also done in the PR). However, because the message is referenced via a pointer and has a combination of getters, setters,Marshal
, andUnmarshal
methods, it doesn't feel entirely safe to assume that access to these will always be sequential. So, enhancing concurrency safety seems like a guarded measure.