Feature/block relative and notes seqn

[cohansen]

Adds block relative and notes to our SeqN, hooked up to the latest version of our seqjson library as well.

Tagging Carter and Shaheer for visibility.

@shaheerk94 @cartermak

[cartermak]

Good chance you've already discussed this, but in case you haven't - should a negative duration be allowed for BLOCK_RELATIVE? I would assume that we don't want to be able to time steps prior to the block start, but I could be missing some use case.

[cohansen]

Good chance you've already discussed this, but in case you haven't - should a negative duration be allowed for BLOCK_RELATIVE? I would assume that we don't want to be able to time steps prior to the block start, but I could be missing some use case.

This is a great question for @shaheerk94, we use the same definition as Epoch currently which includes negatives.

[shaheerk94]

Actually, I just tested it and SEQGEN does allow negative FROM_REQUEST_START durations. In SASF:

request(BKG_file_remove_001, REQUESTOR, "SEQ",
            START_TIME, 2025-056T07:30:00.000000,
            PROCESSOR, "VC2A",
            KEY, "NO_KEY")
        command(1, SCHEDULED_TIME, -00:10:00.000000, FROM_REQUEST_START,
            FILE_REMOVE(
                "/eng/seq/yc015_BKG_STORED_01.abs")
             ),   
    end; 

In SSF (compiled products):

A      FILE_REMOVE 2025-056/07:20:00.000,0793740074:841,VC2A,,"/eng/seq/yc015_BKG_STORED_01.abs"

So we should allow negative BLOCK_RELATIVE durations.

[sonarqubecloud]

Quality Gate failed

Failed conditions
6.9% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[goetzrrGit]

Looks good. I have a question about the Time1 type as this seems weird to have this type interface defined.

[goetzrrGit]

You can make this an else as it is the last thing in the conditional.

else {
      const relativeNode = timeTagRelativeNode || timeTagBlockRelativeNode;
      if (!relativeNode) {
        return diagnostics;
      }

      const from = relativeNode.from;
      const to = relativeNode.to;
      const relativeText = text.slice(from + 1, to).trim();

[goetzrrGit]

I've noticed that we're using timeSecond, timeDOY, and timeHhmmss quite frequently. We can create a new variable

  timeSegments { timeSecond | timeDOY | timeHhmmss} <--- new

  TimeAbsolute { 'A'@digit@digit@digit@digit"-"@digit@digit@digit"T"timeHhmmss whiteSpace }

  TimeRelative { 'R'timeSegments whiteSpace} <-- update

  TimeBlockRelative { 'B'$[+\-]?timeSegments whiteSpace } <-- update

  TimeEpoch { 'E'$[+\-]?timeSegments whiteSpace} <-- update

  TimeGroundEpoch { 'G'$[+\-]?timeSegments whiteSpace} <-- update

[goetzrrGit]

This is really strange. Why is there a new Time1 type? This new RelativeBlock Time tag should be in the Time Type right?

@cartermak @shaheerk94 any thoughts on this?

[cartermak]

It's in the types.ts...I bet it has something to do with the conditional that we added to enforce that everything except COMMAND_COMPLETE needs a tag specified? But reading through types.ts, it doesn't really make sense. I wonder if the auto-generation is struggling with that conditional logic, or maybe I just am bad at TS.

/**

 * Time object

 */

export type Time = Time1 & {

  /**

   * Relative or absolute time. Required for ABSOLUTE, BLOCK_RELATIVE, COMMAND_RELATIVE, and EPOCH_RELATIVE time types but not COMMAND_COMPLETE.

   */

  tag?: string;

  /**

   * Allowed time types: ABSOLUTE, BLOCK_RELATIVE, COMMAND_RELATIVE, EPOCH_RELATIVE, or COMMAND_COMPLETE.

   */

  type: 'ABSOLUTE' | 'BLOCK_RELATIVE' | 'COMMAND_RELATIVE' | 'EPOCH_RELATIVE' | 'COMMAND_COMPLETE';

};

export type Time1 = {

  [k: string]: unknown;

};

[cohansen]

Yeah I was curious about this as well, but I just included it in the new logic. We could remove from the underlying library and I can update my code.

[cartermak]

Have you checked whether it behaves correctly? It seems like all the typing uses Time1, which doesn't seem to actually enforce time restrictions at all? Or maybe there's some logic I missed.