graphql-hive / graphql-hive/envelop
usePrometheus: Two new counters requestTotalCount and requestTotalErrorCount
- Dominant language
- No language data
- Stars
- 827
- Forks
- 132
- PR merge metrics
- No merged PRs in 30d
Description
**Is your feature request related to a problem? Please describe.**
Investigating #1356 closer, I have realized that it wouldn't be possible to increment the existing counter for queries that fail in `parse` step as the `graphql_envelop_request` requires `operationName` and `operationType`, something that simply does not exist without a parsable query. I also found issues with `errorCount` that doesn't
So going back to what we our requirements are here:
- we would like a to know the total number of incoming requests, regardless of operationName/operationType
- we would like a to know the total number of failed requests, regardless of operationName/operationType
I made a small map describing how the current `errorCount` and `requestCount` work today in 5 different scenarios:
- A: Fails in parse
- B: Fails in validate
- C: Resolver throws an error
- D: Resolver returns partial success with N errors
- E: Resolver returns data with no errors
```
| parse | validate | execute | | errorCount | requestCount |
case | | | | result | [phase] | [opName/opType] |
|-------|----------|---------|--------|------------|-----------------|
A | NOK | - | - | ➡️ | 1 | 0 |
B | OK | NOK | - | ➡️ | 1 | 1 |
C | OK | OK | NOK | ➡️ | 1 | 1 |
D | OK | OK | OK* | ➡️ | N | 1 |
E | OK | OK | OK | ➡️ | 0 | 1 |
```
As you can see there are edge cases in a two places:
- A (`requestCount` can never work for this type of error)
- D (`errorCount` becomes `N` instead of `1`)
This means we cannot by default create the dashboard and monitoring we are used to, which are like % request failed and anomaly detection thereof.
**Describe the solution you'd like**
What do we think about introducing two new counters `requestTotalCount` and `requestTotalErrorCount` ?
Going back to the example:
```
| parse | validate | execute | | requestTotalCount* | requestTotalErrorCount* |
case | | | | result | [] | [] |
|-------|----------|---------|--------|--------------------|-------------------------|
A | NOK | - | - | ➡️ | 1 | 1 |
B | OK | NOK | - | ➡️ | 1 | 1 |
C | OK | OK | NOK | ➡️ | 1 | 1 |
D | OK | OK | OK* | ➡️ | 1 | 1 |
E | OK | OK | OK | ➡️ | 1 | 0 |
```
No edge cases, it's easy to calculate in this case that
**Describe alternatives you've considered**
**Additional context**
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by locating usePrometheus and the existing errorCount and requestCount instrumentation, then trace how metrics are recorded across parse, validate, and execute. Done means adding requestTotalCount and requestTotalErrorCount with the issue's A–E behavior, including one total error for failed or partially failed requests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- prometheus
- Domain
- backend-api-design, observability
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100