Cannot assign the FR10 acknowledgement after our application restart

HassanBrown0878 · 22 Oct 2025, 11:52 UTC

Closed
HA
HassanBrown0878
Our FR10 log reuses a housing job label after restart. Which attempt owns the delayed acknowledgement?

21 replies

GA
GabrielChen1149
Replying to HassanBrown0878

Does the acknowledgement carry anything besides that job label, Hassan?

11 points
SA
SamBrooks0855
Replying to HassanBrown0878

Have you kept the original logs separately? I'd avoid adjusting all their times in the only copies.

10 points
GR
GraceBennett0755
Replying to HassanBrown0878

Build the attempt sequence within each source first. You can then look for shared events or identifiers to relate them, without assuming the wall clocks were aligned.

15 points
HA
HassanBrown0878
Replying to GabrielChen1149

Gabriel, label only in the application display. Sam, original files are untouched.

9 points
AN
AnilAbbott0027
Replying to HassanBrown0878

Look at what the receiver actually returned, not just the display. On another interface discussion the important question was what the receiver retained, and a friendly label on the slide did not answer it.

14 points
GA
GabrielChen1149
Replying to GraceBennett0755

Grace, would you use connection loss as a common event, or is that too loose?

16 points
GR
GraceBennett0755
Replying to GabrielChen1149

It can bound part of the sequence, but different components may detect the loss at different times. I would not align their clocks on that event alone, especially when a timeout is involved.

18 points
SA
SamBrooks0855
Replying to GraceBennett0755

That's helpful, Grace. I was about to use the two disconnect entries as though they were simultaneous.

16 points
HA
HassanBrown0878
Replying to AnilAbbott0027

The raw reply has a sequence field. Our display hides it. Thank you, Anil.

13 points
AN
AnilAbbott0027
Replying to HassanBrown0878

Now check what the request carried and whether that sequence can repeat after restart. Finding another number is useful; it isn't the match until its meaning is clear.

24 points
GA
GabrielChen1149
Replying to HassanBrown0878

Hassan, does the saved request include that field too?

22 points
HA
HassanBrown0878
Replying to GabrielChen1149

Yes. Different values on the two sends.

18 points
GR
GraceBennett0755
Replying to HassanBrown0878

If the protocol defines the returned field as the request sequence, compare those saved values directly. Keep the protocol meaning with the report, since an unrelated internal counter could look equally convincing.

6 points
SA
SamBrooks0855
Replying to AnilAbbott0027

Anil, would you still compare the controller events once a request match is found?

9 points
AN
AnilAbbott0027
Replying to SamBrooks0855

Yes, Sam, for what the controller was doing. A matched acknowledgement may only say the request arrived. Don't turn it into a completed inspection unless that is what the interface says it means.

12 points
HA
HassanBrown0878
Replying to GraceBennett0755

Protocol says request received, with its sequence echoed. It matches the earlier send.

15 points
GA
GabrielChen1149
Replying to HassanBrown0878

So is the newer attempt still unanswered, Hassan?

25 points
GR
GraceBennett0755
Replying to HassanBrown0878

For the handover, keep the earlier receipt beside the earlier request and show the later attempt separately. Any eventual inspection result needs its own interpretation; the receipt should not fill that blank.

6 points
HA
HassanBrown0878
Replying to GabrielChen1149

Newer receipt unknown, Gabriel. Neither inspection outcome is established from this reply.

23 points
SA
SamBrooks0855
Replying to HassanBrown0878

Did the application treat that earlier receipt as success for the newer attempt, or only display it?

14 points

Discussion closed

This discussion is closed to new replies after six months without activity. Last activity: .