clay icon indicating copy to clipboard operation
clay copied to clipboard

Check deadlines in different timezones

Open maaktweluit opened this issue 5 years ago • 1 comments

Description

Golem Version: 0.22.0

Golem-Messages version (leave empty if unsure):

Electron version (if used):

OS [e.g. Windows 10 Pro]: mac

Branch (if launched from source):

Mainnet/Testnet: mainnet

Priority label is set to the lowest by default. To setup higher priority please change the label P0 label is set for Severity-Critical/Effort-easy

Description of the issue:

A clear and concise description of what went wrong, in which component, when and where. User from another timezone ( UTC -5 ) gets a lot ( 75k per day ) of

2020-01-16 07:27:47 INFO     golem.task.taskserver               Task's deadline already in the past. task_id='1dadd59e-3797-11ea-bd3b-ead88c641f8e' 

I suspect this is related to the recent change to checking all deadlines in UTC (#4978)

Actual result:

What is the observed behavior and/or result in this issue No tasks are picked up, they all have a deadline in the past

Screenshots:

If applicable, add screenshots to help explain your problem.

Steps To Reproduce

Short description of steps to reproduce the behavior: e.g. Run 2 nodes in different time zones, request task on one.

Expected behavior

(What is the expected behavior and/or result in this scenario)

Logs and any additional context

(Any additional information that could help to resolve the issue, which systems were checked to reproduce the issue) Please upload your logs if possible Logs are send to [email protected], ask me, Ola or Blue for the logs.

Proposed Solution?

(Optional: What could be a solution for that issue) Think this bug is related to #4978 it fixed it for task-api, but probably broke it for old style tasks

maaktweluit avatar Jan 16 '20 15:01 maaktweluit

While it's possible that there's an issue with how timestamps are compared I noticed a different problem.

Tasks (and started subtasks) are getting stuck on requestor's side. After some investigation I found that this is caused by DoWorkService stopping at some point. One consequence here is that ongoing subtasks are not being processed by the requestor. Another side effect is that tasks which should be marked as timed out remain in an active state until they are eventually removed by TaskCleanerService (if enabled).

I haven't figured out why the service stops running yet, but I thought this might be valuable input here.

kmazurek avatar Feb 07 '20 14:02 kmazurek