Description
If you have a Slurm job without a time limit, the squeue command returns a value of 'UNLIMITED'. This is being processed by the Slurm adapter to a wallclock_limit of integer 0. The batch_connect helper includes a function to generate a localized description of the job session time. This function will determine if a job is not running, in case it will show the time requested. If the job is running or pending, it will then attempt to determine if there is a time limit, and if so it will display the time remaining, otherwise it will display the time already used with this logic:
if session.starting? || session.running?
if time_limit && time_used
[t('dashboard.batch_connect_sessions_stats_time_remaining'), distance_of_time_in_words(time_limit - time_used, 0, false, : [:minutes, :hours], :accumulate_on => :hours)]
elsif time_used
[t('dashboard.batch_connect_sessions_stats_time_used'), distance_of_time_in_words(time_used, 0, false, : [:minutes, :hours], :accumulate_on => :hours)]
end
else
if time_limit
[t('dashboard.batch_connect_sessions_stats_time_requested'), distance_of_time_in_words(time_limit, 0, false, : [:minutes, :hours], :accumulate_on => :hours)]
end
end
The issue is that in Ruby 0 is not falsy and evaluates to true, so in all cases I can find time_limit is an integer so this check will always pass. I believe either the Slurm adapter utility function to convert the wall time to seconds should return nil if there is no time (which could have unintended consequences for consumers of that value, I suppose), or the session_time() function should check for a time_limit > 0 instead.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status