inter service context propagation docs #1082
Conversation
NimrodAvni78
force-pushed
the
nimrodavni78/internal-context-propagation-docs
branch
from
a83195a to
79dcf7f
Compare
Codecov Report✅ All modified and coverable lines are covered by tests.
Additional details and impacted files@@ Coverage Diff @@
## main #1082 +/- ##
==========================================
- Coverage 56.97% 48.51% -8.47%
==========================================
Files 260 260
Lines 22786 22786
==========================================
- Hits 12982 11054 -1928
- Misses 8938 11041 +2103
+ Partials 866 691 -175
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| |:--------------------|:---------:|---------------:|:--------------------------------------------------|:------------- | ||
| | Go Routines | Go | Go >= 1.18 | up to 3 nested levels of goroutines | Stable | ||
| | Node.js Async Hooks | Node.js | Node.js >= 8.0 | Custom handling of SIGUSR1 signal might interfere | Stable | ||
| | Ruby Puma Server | Ruby | N/A | Only works with Puma server | Stable |
There was a problem hiding this comment.
Why is this limited to a Puma server? I've seen this work with webrick?
| | Go Routines | Go | Go >= 1.18 | up to 3 nested levels of goroutines | Stable | ||
| | Node.js Async Hooks | Node.js | Node.js >= 8.0 | Custom handling of SIGUSR1 signal might interfere | Stable | ||
| | Ruby Puma Server | Ruby | N/A | Only works with Puma server | Stable | ||
| | Java Thread pool | Java | N/A | N/A | Stable |
There was a problem hiding this comment.
Why N/As here? There definitely should be limitations on versions at least.
There was a problem hiding this comment.
for java and ruby i couldn't find if we have any limitations, maybe @grcevski can chime in
| processes. | ||
| OBI has support for several asynchronous frameworks that allow it to propagate context in these scenarios. | ||
|
|
||
| | Framework | Languages | Versions | Limitations | Status |
There was a problem hiding this comment.
i can write them in Not supported status
we have plans to implement Rust tokio support in the future, im not familiar with common C++ asynchronies frameworks
| | github.com/IBM/sarama | Kafka | >= 1.37 | All | Yes | No | N/A | ||
| | go.mongodb.org/mongo-driver | MongoDB | >= v1.10.1, >= v2.0.1 | All | Yes | No | N/A | ||
|
|
||
| # Supported Context propagation frameworks |
There was a problem hiding this comment.
I think this grouping is going to be overwhelming.
I would recommend we group our documentation by language:
## Go
...
### Context Propagation
...
### Supported Libraries
...
### SDK Integration
...
## Java
...
### Context Propagation
...
Structuring the currently proposed way severly limits the ability to eplain things by having it in a table and without other languge context. Addtionally, this is not how users will use this documentation, they will first ask about a specific Language and then look for its supported features.
There was a problem hiding this comment.
still leaving the top table for protocols? and after grouping by language and write custom probes under that?
2 participants
Checklist