-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: Add documentation about the path of an event through relay #289
Conversation
The HTTP response is out, with a status code that is just a best-effort guess | ||
at what the actual outcome of the event is going to be. The rest of what used | ||
to happen synchronously in the Python `StoreView` is done asynchronously, but | ||
still in the same process. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe slightly more clear would be:
The HTTP response returned is just a best-effort guess at what the actual outcome of the event is going to be. We only return a 4XX code if we know that the response will fail (based on cached information), if we don't we return a 200 and continue to process the event asynchronously. This asynchronous processing used to happen synchronously in the Python implementation of StoreView
.
The effect of this is that the server will respond much faster that before but we might return 200 for events that will ultimately not be accepted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it 👍
A quick comment about relay modes.
|
||
* Event normalization does different (less) things. | ||
|
||
* In `static` mode, project config is read from disk instead of fetched from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we perhaps link to the modes description here?
Also, is "processing" also a mode, or more like, a feature? If the former, we should probably add it to the modes list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to keep this out of this document. I want to remove some of these modes once the original mode (fetching from sentry) is GA.
We have graphs now! |
Nice graphs, yo! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🏄
* master: (26 commits) doc: Add documentation about the path of an event through relay (#289) release: 0.4.59 meta: Changelog for 0.4.59 ref: Set _relay_processed to true (#293) feat(protocol): Add valid platforms as constant (#294) fix(protocol): Add missing legacy alias for stacktrace (#292) release: 0.4.58 meta: Add changelog for 0.4.58 feat: Expose globbing code from Semaphore to Python (#288) fix: Add code comment fix: Normalize before datascrubbing (#290) feat(projects): Evict project caches after some time (#287) feat: Add mkdocs like in symbolicator ref: Add event size metrics (#286) test: add panic test ref: Selectively log internal errors to stderr (#285) fix(cabi): Do not ignore process_value result in scrub_event (#284) feat(config): Add a config value for thread counts (#283) fix: Refactor outcomes for parity with Sentry (#282) feat: Add an error boundary to parsing project states (#281) ...
Run
make docserver
locally to get a nice view, but the github md renderer works too.EDIT: Temporary deployment: https://getsentry.github.io/semaphore/architecture/ingest-event-path/