https://dagster.io/ logo
Join Slack
Powered by
Hi, I found ui display after upgrade dagster and d...
# announcements
t
Hi, I found ui display after upgrade dagster and dagit from v0.8.7 to v0.9.2:
1. All schedulers in 
Scheduler
menu on top left display my scheduler twice. I have an only one scheduler at this time. 2. I change the scheduler time to 
10:37
but the time that display in Scheduler menu still display 
At 10:00 AM
but when I click scheduler pipline on the buttom left, I see it display 
At 10:37 AM
which is correct. (See the image on my thread).
This is the result from inspecting websocket response.
scheduleStates
The issue might apollo fetch policy. After I change that to 
no-cache
in this line https://github.com/dagster-io/dagster/blob/master/js_modules/dagit/src/schedules/SchedulerRoot.tsx#L20. It show 2 entry which response from graphql api correctly.
a
cc @sashank can you run 
dagster schedule debug
and share the output ?
t
@alex @sashank
Copy code
Scheduler Info
==============
Running Cron Jobs:
37 10 * * * /opt/dagster/local/schedules/scripts/762e0a64621807622bed9c1e4e23913894d68c44.sh > /opt/dagster/local/schedules/logs/762e0a64621807622bed9c1e4e23913894d68c44/scheduler.log 2>&1 # dagster-schedule: 762e0a64621807622bed9c1e4e23913894d68c44


Scheduler Storage Info
======================
calculate_bot_spending_daily:
  cron_schedule: 0 10 * * *
  pipeline_origin_id: 762e0a64621807622bed9c1e4e23913894d68c44
  python_path: /usr/local/bin/python
  repository_origin_id: c2277a61aeb3c20452da8f00241590c3295970f1
  repository_pointer: -f /lfc_pipeline/repository.py -a lfc_repository
  schedule_origin_id: 762e0a64621807622bed9c1e4e23913894d68c44
  status: RUNNING

export_reward_redemptions_daily:
  cron_schedule: '*/2 * * * *'
  pipeline_origin_id: 80f46335e5e3efb6224abf1a2a6bf54a74619265
  python_path: /root/.local/share/virtualenvs/lfc_pipeline-idEoWM_E/bin/python
  repository_origin_id: 162bd720de7438181349f39f6059e63e30f7d81f
  repository_pointer: -f /lfc_pipeline/repository.py -a lfc_repository
  schedule_origin_id: 80f46335e5e3efb6224abf1a2a6bf54a74619265
  status: RUNNING

calculate_bot_spending_daily:
  cron_schedule: 37 10 * * *
  pipeline_origin_id: 762e0a64621807622bed9c1e4e23913894d68c44
  python_path: /usr/local/bin/python
  repository_origin_id: c2277a61aeb3c20452da8f00241590c3295970f1
  repository_pointer: -f /lfc_pipeline/repository.py -a lfc_repository
  schedule_origin_id: 762e0a64621807622bed9c1e4e23913894d68c44
  status: RUNNING
I think I encounter 2 problems:
The first one is I have 2 schedule with the same id after upgrade. And the second is dagit ui use old data because it already cache the first entry, which is schedule 
0 10 * * *
.
a
Having the two entries in schedule storage is very surprising and could cause the front end confusion too since we have two items with the same ID which is not expected
t
@alex May I know the table that store schedules in the database?
a
how do you have your instance configured? Can you look at the Instance Details section, button in the top left of dagit
t
Copy code
local_artifact_storage:
     module: dagster.core.storage.root
     class: LocalArtifactStorage
     config:
       base_dir: /opt/dagster/local/

run_storage:
     module: dagster_postgres.run_storage
     class: PostgresRunStorage
     config:
       postgres_db:
  db_name:
    env: DAGSTER_PG_DB
  hostname:
    env: DAGSTER_PG_HOST
  password:
    env: DAGSTER_PG_PASSWORD
  port: 5432
  username:
    env: DAGSTER_PG_USERNAME

event_log_storage:
     module: dagster_postgres.event_log
     class: PostgresEventLogStorage
     config:
       postgres_db:
  db_name:
    env: DAGSTER_PG_DB
  hostname:
    env: DAGSTER_PG_HOST
  password:
    env: DAGSTER_PG_PASSWORD
  port: 5432
  username:
    env: DAGSTER_PG_USERNAME

compute_logs:
     module: dagster.core.storage.local_compute_log_manager
     class: LocalComputeLogManager
     config:
       base_dir: /lfc_pipeline/storage

schedule_storage:
     module: dagster_postgres.schedule_storage
     class: PostgresScheduleStorage
     config:
       postgres_db:
  db_name:
    env: DAGSTER_PG_DB
  hostname:
    env: DAGSTER_PG_HOST
  password:
    env: DAGSTER_PG_PASSWORD
  port: 5432
  username:
    env: DAGSTER_PG_USERNAME

scheduler:
     module: dagster_cron.cron_scheduler
     class: SystemCronScheduler
     config:
       {}

run_launcher:
     module: dagster
     class: DefaultRunLauncher
     config:
       {}

telemetry:
     enabled: false
     
opt_in:
     NoneType
Can I request feature copy dagster detail to clipboard 😂.
😂 1
a
schedules
table
t
A bit more surprises 😂
a
can you put that in to a 
gist
or something I am having a hard time reading the screenshot
t
a
ugh ok yea, I think the best thing to delete that row with schedule id 
077556779d6339d405eedf4cf6e173e19e7d76b8
or just run 
dagster schedule wipe
if you dont care about losing 
tick
data
t
@alex Issue was solved by running 
dagster schedule wipe
. But why it’s happening. 🤔
Ok. Now I can reproduce this issue: 1. I create 1 
daily_schedule
from v0.8.7. 2. Then I ran 
dagster schedule up
and turn schedule on in dagit. See 1 schedules pipeline in the schedule menu. 3. Upgrading dagster and dagit to v0.9.2. 4. Run 
dagster schedule up
again. 5. Found two schedules show in schedule menu and both of are turn off in the image below:
a
yeah I know whats happening, thanks a ton for the report and following up with details
s
Thank you for the accurate repro
t
Thanks for your help. This is more information about data in schedules table. Wish this can help https://gist.github.com/wingyplus/1bad2ffb396b422aa42da7a56a840b03.
s
This is a deeper issue in the system that we’ll need to solve over time. It also shouldn’t come up too often. But for now, after you upgrade, running 
dagster schedule wipe
before 
dagster schedule up
will put you in the right state
t
Noted. Thanks.
Open in Slack
PreviousNext
Powered by