Scheduler does not respect mutex condition

[parkerabercrombie]

Checked for duplicates

No - I haven't checked

Is this a regression?

Yes - This worked in a previous version

Version

2.11.0

Describe the bug

I ran scheduling with two goals (in priority order):

B/6hr

export default (): Goal => {
  return Goal.ActivityRecurrenceGoal({
    interval: Temporal.Duration.from({hours: 6}),
     activityTemplate: ActivityTemplates.TEL_Set_GroupID({ groupID: 34 }) }) }

A/1d

export default (): Goal => {
  return Goal.ActivityRecurrenceGoal({
    interval: Temporal.Duration.from({days: 1}),
    activityTemplate:ActivityTemplates.GENERIC_Placeholder({
      duration:"000T12:00:00",
      team: "TEST",
      activityName: "TEST" }) }) }

And one scheduling condition:

 export default (): GlobalSchedulingCondition => {
  return GlobalSchedulingCondition.mutex(
    [ActivityType.GENERIC_Placeholder], [ActivityType.TEL_Set_GroupID]
); }

When I run the scheduler I get a plan with overlapping GENERIC_Placeholder and TEL_Set_GroupID activites, which is in violation of the scheduling condition.

Plan start: 2030-001T00:00:00.000 Plan end: 2030-005T00:00:00.000

Reproduction

See bug description above.

Logs

N/A

System Info

Chrome

Severity

Moderate

[parkerabercrombie]

Clipper is not relying on scheduling conditions for current conop, so not a high priority bug for us.

[dandelany]

Thanks @parkerabercrombie - related to or duplicate of #1336

[adrienmaillard]

@parkerabercrombie @srschaffJPL So far, can't reproduce. I have a mission model jar from march 18, 2024. When I try running this example, I get an error on the compilation of this global scheduling condition. It seems there is an issue with GENERIC_Placeholder activity type being absent from generated types. I have GENERIC_Power_Data and GENERIC_Epoch but not GENERIC_Placeholder. (1) do you have any other goal with that activity type ? do you use it otherwise ? is it draggable from the UI ? (2) Can you LFT me your mission model jar ?

[adrienmaillard]

The issue has been reproduced with a g24.1 clipper model on develop.

[dandelany]

This is now fixed in Aerie 2.14.0, closing this, thanks @adrienmaillard