can it happen that the for the same job there are two different "submitted" times

[volodymyrss]

[burnout87]

Interesting! Perhaps we should apply the same approach used to prevent multiple "done" emails.

[volodymyrss]

Yeah, perhaps. But can it be at all that the submitted time changed, for the same job_id?.. It also differs from the original submitted time - the was another email earlier:

[burnout87]

It can be that a sufficient amount of time has passed from the last submitted for the same job_id, this is set with intsub in the token, or, if not, in the configuration. So, yes it's possible, is it possible to investigate the content of the token?

[volodymyrss]

here

{
    "email": "[email protected]",
    "exp": 1638890893,
    "name": "cferrigno",
    "roles": "authenticated user, administrator, user manager, content manager, general, integral-private-qla, magic, unige-hpc-full, public-pool-hpc, antares, sdss",
    "sub": "[email protected]"
}

you could get it with the inspect-state functionality.

edit: to get it yourself:

curl "https://www.astro.unige.ch/mmoda/dispatch-data/inspect-state?job_id=8b251782&token=$ODA_TOKEN" | jq '.records[] | .analysis_parameters.token'

[burnout87]

and what about the configuration? the email_sending_job_submitted_default_interval configuraiton is used in case intsub filed was not present within the token

[volodymyrss]

and what about the configuration? the email_sending_job_submitted_default_interval configuraiton is used in case intsub filed was not present within the token

you can see in as curl https://www.astro.unige.ch/mmoda/dispatch-data/run_analysis | jq

https://github.com/oda-hub/doc-operations/blob/main/README.md#dispatcher-endpoints

I think the purpose of intsub was to deal with jobs which might be stuck in submitted for very long time. Like, if they never finish - the user will never get another email, e.g. for the default job - even if it was a year ago. Actually, maybe better to use token expiration for this, hm. Or, combination of the two: max(intsub, token_expiration)

Meanwhile, we should increase intsub to, say, 2 weeks?

Also, so is the time of submitted time changes with new email? I guess it makes sense.

[burnout87]

https://github.com/oda-hub/doc-operations/blob/main/README.md#dispatcher-endpoints

BTW I will need the job(s) manager role to inspect the various states

I think the purpose of intsub was to deal with jobs which might be stuck in submitted for very long time. Like, if they never finish - the user will never get another email, e.g. for the default job - even if it was a year ago. Actually, maybe better to use token expiration for this, hm. Or, combination of the two: max(intsub, token_expiration)

A combination of the two makes more sense I'd say

Meanwhile, we should increase intsub to, say, 2 weeks?

I don't know how much is by default, that is why I am asking

Also, so is the time of submitted time changes with new email? I guess it makes sense.

If you are referring to the time mention within the email subject, that is the time the specific request is actually submitted, so that is different for every email

[volodymyrss]

https://github.com/oda-hub/doc-operations/blob/main/README.md#dispatcher-endpoints

BTW I will need the job(s) manager role to inspect the various states

I think the purpose of intsub was to deal with jobs which might be stuck in submitted for very long time. Like, if they never finish - the user will never get another email, e.g. for the default job - even if it was a year ago. Actually, maybe better to use token expiration for this, hm. Or, combination of the two: max(intsub, token_expiration)

Ok so that's the needed action here.

A combination of the two makes more sense I'd say

Meanwhile, we should increase intsub to, say, 2 weeks?

I will set it.

I don't know how much is by default, that is why I am asking

but you could check yourself! here is the command again (needs no token, you see):

curl https://www.astro.unige.ch/mmoda/dispatch-data/run_analysis | jq

it's 10h

Also, so is the time of submitted time changes with new email? I guess it makes sense.

If you are referring to the time mention within the email subject, that is the time the specific request is actually submitted, so that is different for every email

the request was actually first submitted once one per job. This is the time which should be used in the title. The title literally says "first requested". That's when it was actually submttied (first)

[burnout87]

the request was actually first submitted once one per job. This is the time which should be used in the title. The title literally says "first requested". That's when it was actually submttied (first)

So, in case of multiple "submitted" of the same job, the time to use in the title, should be the time of the first request. Correct?

Then I will apply the change

[volodymyrss]

#305 #304