6.4.2.11 IntegrationGap
6.4.2.11.1 Purpose¶
Something we cannot read yet, recorded once however many farms meet it: a source version no client adapter covers, or a file structure no parser understands. Failures are grouped by a fingerprint of the side, the channel, the detected version and the structure of the input, so the same problem from ten farms is one gap with ten occurrences. Support works through the open gaps by the farms they affect; when a new adapter resolves a gap, the runs and parse jobs that failed on it are retried.
6.4.2.11.2 Questions it answers¶
- Which sources or structures can we not read yet, and how many farms do they affect?
- Who is working on a gap, and which adapter resolved it?
- What does the input look like, without opening customer data?
6.4.2.11.3 Fields¶
| Field | Type | Cardinality | Description |
|---|---|---|---|
id |
string (uuid) |
1..1 |
Key. |
fingerprint |
string |
1..1 |
Unique. Hash of side, channel, detected version and structure signature: what makes two failures the same problem. |
side |
enum | 1..1 |
Values: client, parser, puller. |
source_channel |
SourceChannel | 0..1 |
Empty when the source was not recognised at all. |
detected_version |
string |
0..1 |
|
structure_signature |
string (JSON) |
1..1 |
The shape of the input without its values: table and column names, file headers, the fields of an API answer. It can be read without opening customer data. |
status |
enum | 1..1 |
Values: open, investigating, supported, wont_support. Default: open. |
assignee |
MoonitoringUser | 0..1 |
|
resolved_by |
AdapterMapping | 0..1 |
The mapping that now covers it; set when status = supported. Runs and jobs that failed on this gap are then retried: the client with its next configuration, after an update when the mapped adapter needs one, the parsers with a ParseJob of trigger parser_change (ParseJob.trigger). |
note |
string |
0..1 |
What support learned, in a few lines. |
system_version |
SystemVersion | 1..1 |
|
created_at |
datetime |
1..1 |
|
updated_at |
datetime |
1..1 |
6.4.2.11.4 Relationships¶
References
IntegrationGap.source_channel→ SourceChannel (0..1)IntegrationGap.assignee→ MoonitoringUser (0..1)IntegrationGap.resolved_by→ AdapterMapping (0..1)
Referenced by
IntegrationGapOccurrence.gap(1..1)
Uses types
6.4.2.11.5 Rules & constraints¶
- Something we cannot read yet, recorded once however many farms and users meet it: a source version no client adapter covers, or a file structure no parser understands. Occurrences (IntegrationGapOccurrence) group under one gap by fingerprint, so the same problem from ten farms is one gap with ten occurrences, not ten reports.
- First and last seen, how many farms and how many occurrences are read from IntegrationGapOccurrence, not stored here.