[Bug]: Schedule cron parameter silently position sensitive and can be dropped if in the wrong place

[parkan]

Description

golang arg parsing is always a fun game and it's particularly fun with many submodules/subcommands

we recently noticed that our schedule commands were dropping the cron parameter:

$ ./singularity deal schedule create --provider XXXX --preparation XXXX --url-template http://127.0.0.1:8889/piece/{PIECE_CID} --start-delay 336h --duration 30312h --keep-unsealed false --schedule-cron '0 * * * *' --schedule-deal-number 2

would insert an empty cron value:

("created_at","updated_at","url_template","http_headers","provider","price_per_gb_epoch","price_per_gb","price_per_deal","total_deal_number","total_deal_size","verified","keep_unsealed","announce_to_ipni","start_delay","duration","state","schedule_cron","schedule_cron_perpetual","schedule_deal_number","schedule_deal_size","max_pending_deal_number","max_pending_deal_size","notes","error_message","allowed_piece_cids","force","preparation_id") VALUES ('2024-09-19 09:54:48.727','2024-09-19 09:54:48.727','http://127.0.0.1:8889/piece/{PIECE_CID}','{}','XXXXX',0.000000,0.000000,0.000000,0,0,true,true,true,1209600000000000,109123200000000000,'active','',false,0,0,0,0,'','','null',false,'XXXX') RETURNING "id"        {"rowsAffected": 1, "elapsed": 4.669062167, "err": null}
ID   Provider   TotalDealSize  Verified  StartDelay  Duration    State   ScheduleCron  ScheduleCronPerpetual  ScheduleDealNumber  ScheduleDealSize  MaxPendingDealNumber  MaxPendingDealSize  Notes  Force  PreparationID  
824  XXXX  0              true      336h0m0s    30312h0m0s  active                false                  0                   0                 0                     0                          false  XXXX

we discovered that this happened due to the addition of --keep-unsealed false, as the same command without that parameter inserts a correct schedule

luckily (?) this seems to be a simple parsing issue, as rearranging the parameters gives a correct schedule:

$ ./singularity deal schedule create --number 1 --url-template http://127.0.0.1:8889/piece/{PIECE_CID} --duration 30312h --keep-unsealed=false --price-per-deal 0 --price-per-gb 0 --price-per-gb-epoch 0 --start-delay 336h --verified --schedule-cron "*/45 * * * *" --preparation XXXX --provider XXXX
("created_at","updated_at","url_template","http_headers","provider","price_per_gb_epoch","price_per_gb","price_per_deal","total_deal_number","total_deal_size","verified","keep_unsealed","announce_to_ipni","start_delay","duration","state","schedule_cron","schedule_cron_perpetual","schedule_deal_number","schedule_deal_size","max_pending_deal_number","max_pending_deal_size","notes","error_message","allowed_piece_cids","force","preparation_id") VALUES ('2024-09-20 11:54:01.569','2024-09-20 11:54:01.569','http://127.0.0.1:8889/piece/{PIECE_CID}','{}','XXXX',0.000000,0.000000,0.000000,0,0,true,false,true,1209600000000000,109123200000000000,'active','*/45 * * * *',false,1,0,0,0,'','','null',true,'XXXX') RETURNING "id"    {"rowsAffected": 1, "elapsed": 1.660162042, "err": null}
ID   Provider   TotalDealSize  Verified  StartDelay  Duration    State   ScheduleCron  ScheduleCronPerpetual  ScheduleDealNumber  ScheduleDealSize  MaxPendingDealNumber  MaxPendingDealSize  Notes  Force  PreparationID  
841  XXXX  0              true      336h0m0s    30312h0m0s  active  */45 * * * *  false                  1                   0                 0                     0                          true   XXXX

this implies that the arg parser needs to either be more flexible or error out (as it does if the --keep-unsealed is moved to the beginning of the command line)

[parkan]

upon review this appears to be in part due to --keep-unsealed requiring = when specifying false, this is a golang flag behavior that's easy to shoot yourself in the foot with (i.e. it turns into --keep-unsealed=true false)

we shoud likely more consistently panic on unexpected args like false to avoid this