Handling of PartnerIncidentIds

[vollraths]

How does MyIT handle PartnerIncidentIds, are they treated as unique values forever and can never be reused or are they like a key used to deduplicate against and limited to active period of the associated ticket?

Maybe some background to illustrate where I come from:
When a Job experiences errors I take data that distinctly describes the situation (involved client, involved instances, error code) and create a hash and uuid of that to be used as PartnerIncidentId.
That way if a subsequent Job fails with the same conditions i get the same uuid and can update the incident associated with that PartnerIncidentId and not accidentally create dozens of incidents for the same error condition.
That works fine as long as the Incident remains active.

Question is, what happens when the original Issue is closed? When I look up the PartnerIncidentId generated for the condition I probably get a incident back with state 6 or 7, implying that I should create a new Incident. Now when I go and create a new Incident with that same PartnerIncidentId again, would it treat it as a new cycle/instantiation of the error condition and return a new IncidentId or would it throw 409 due to the ID already existing?
When I have to create a PartnerIncidentId that is truly unique and never repeats, how is the indented process to figure out whether or not that ID would create a Duplicate Incident? in sense of content, not IDs.

Please consider intention to be stateless, aka not keeping records on our end which incidents we opened and not wanting to regularly check and update their state in our shadow-records.

[timschaeren]

PartnerIncidentIds are unique values per partnerId and they are unique as long as the incident exists (so, in practical terms: forever). In my opinion, IDs should serve as identifiers of Incidents - ergo actual tickets, but I do see your usecase. I don't see why a partnerIncidentId should not be "freed-up" when an incident is closed. Let me try and rewrite the validation to allow for partnerIncidentIds to be reused as long as there are no non-closed incidents with that id. I'll get back to you shortly.

[timschaeren]

That was easier than anticipated - partnerIncidentId is now freed-up for reuse once an incident is closed.
Let me know if that works for you.

[vollraths]

Is the partnerIncidentId no longer free'd or is query not reporting correct data?
GET https://myit-dev.post.ch/api/x_ssagd_inc_rest/rest/incident?partnerId=commvault&partnerIncidentId=d72ca292-2680-314e-9bef-752386daf2e6
{"name":"MyItRestException","message":"No non-closed Incident found corresponding to identifier 'd72ca292-2680-314e-9bef-752386daf2e6' from partner system 'commvault'.","status":404}
from that I assumed partnerIncidentId is free to use again
POST https://myit-dev.post.ch/api/x_ssagd_inc_rest/rest/incident {"partnerId" : "commvault", "partnerIncidentId":"d72ca292-2680-314e-9bef-752386daf2e6", "short_description" : " SAP HANA PB8 PB8 : SAP HANA Error", "description":"ErrorCode: [18:146]\nFailureReason: Alert every 1 attempts (Phase failures); SAP HANA Error [hdbsql execution Failed.Database may not be online; Otherwise check the connection credentials].\nRecommended Action: https://wikit.post.ch/display/ZDS/18:146\n\nJobDetails:\nJobType: Backup\nStatus: Failed\nJobID: 4157860\nClientName: PB8\nAgentName: SAP HANA\nInstance: PB8\nBackupSet: PB8\nSubClient: default\nStartTime: Mon Sep 30 21:00:19 2024\nEndTime: n/a\nCommCell: CommServe2 (hcszf02.pnet.ch)", "channel" : "monitoring", "location" : "", "assignment_group" : "", "causing_ci" : "7c7268f3877bb5503efcec230cbb354e", "cmdb_ci" : ""}
Returned a 409 {"name":"MyItRestException","message":"A non-closed Incident with identifier 'd72ca292-2680-314e-9bef-752386daf2e6' from partner system 'commvault' already exists in the system.","status":409}
Did I create a race condition by sending to many requests in short time or might it be on SNow side?

[timschaeren]

You assume correctly that the 404 to the GET indicates the ID is freed up. I cannot recreate your issue. - which leads me to believe an actual race condition may be at play here. Did you encounter the issue since then?

[vollraths]

last two so far happened in October almost a month ago, but its also a somewhat slow time with job-failures, might change with windows patch panic before frozen zone