Lilly
May 13, 2026, 6:49pm
1
trying to figure out how to work with the new discourse-patch-triage bot when doing PRs from our own fork, and it’s a bit confusing, especially in a 3-way conversation with it and a team reviewer. is there a proper way to do this?
i can’t order it to fix it’s suggested fixes on my fork. at the moment, i am trying to address it’s replies around spec tests and i am not at all sure if i am doing it correctly - i would rather tell it to fix them since since this seems to be an option suggested.
for example, i am fixing spec tests failures on my fork for the pr but it seems like there is some friction between what i am doing and what the bot wants to do:
main ← Lillinator:automation-recurring-month-fix
Ah this is from a fork, which patch-triage does not support writing to directly.… @patch-triage, how do I fix these tests?
```
Failures:
1) Recurring scheduling next pending automations with monthly frequency doesn't fail to schedule if the current time is within subsecond of the time component of start_date
Failure/Error: example_procsy.run
2023-11-01 07:30:00 UTC is not within 1 millisecond of 2023-11-05 07:30:00 UTC
# ./plugins/automation/spec/triggers/recurring_spec.rb:167:in 'block (4 levels) in <main>'
# ./spec/rails_helper.rb:756:in 'block (3 levels) in <top (required)>'
# /var/www/discourse/vendor/bundle/ruby/3.4.0/gems/timeout-0.6.1/lib/timeout.rb:296:in 'block in Timeout.timeout'
# /var/www/discourse/vendor/bundle/ruby/3.4.0/gems/timeout-0.6.1/lib/timeout.rb:304:in 'Timeout.timeout'
# ./spec/rails_helper.rb:746:in 'block (2 levels) in <top (required)>'
# ./spec/rails_helper.rb:703:in 'block (2 levels) in <top (required)>'
# /var/www/discourse/vendor/bundle/ruby/3.4.0/gems/webmock-3.26.2/lib/webmock/rspec.rb:39:in 'block (2 levels) in <top (required)>'
2) Recurring when trigger is called every_month creates the next iteration one month later
Failure/Error: example_procsy.run
2021-07-04 08:00:00 UTC is not within 1 minute of 2021-07-02 08:00:00 UTC
# ./plugins/automation/spec/triggers/recurring_spec.rb:408:in 'block (4 levels) in <main>'
# ./spec/rails_helper.rb:756:in 'block (3 levels) in <top (required)>'
# /var/www/discourse/vendor/bundle/ruby/3.4.0/gems/timeout-0.6.1/lib/timeout.rb:296:in 'block in Timeout.timeout'
# /var/www/discourse/vendor/bundle/ruby/3.4.0/gems/timeout-0.6.1/lib/timeout.rb:304:in 'Timeout.timeout'
# ./spec/rails_helper.rb:746:in 'block (2 levels) in <top (required)>'
# ./spec/rails_helper.rb:703:in 'block (2 levels) in <top (required)>'
# /var/www/discourse/vendor/bundle/ruby/3.4.0/gems/webmock-3.26.2/lib/webmock/rspec.rb:39:in 'block (2 levels) in <top (required)>'
Finished in 5 minutes 23 seconds (files took 0 seconds to load)
11658 examples, 2 failures, 4 pending, 1 error occurred outside of examples
Failed examples:
rspec ./plugins/automation/spec/triggers/recurring_spec.rb:149 # Recurring scheduling next pending automations with monthly frequency doesn't fail to schedule if the current time is within subsecond of the time component of start_date
rspec ./plugins/automation/spec/triggers/recurring_spec.rb:404 # Recurring when trigger is called every_month creates the next iteration one month later
Retrying failed examples and logging flaky tests...
Run options: include {locations: {"./plugins/automation/spec/triggers/recurring_spec.rb" => [149, 404]}}
Randomized with seed 8900
Recurring
scheduling next pending automations
with monthly frequency
doesn't fail to schedule if the current time is within subsecond of the time component of start_date (FAILED - 1)
when trigger is called
every_month
creates the next iteration one month later (FAILED - 2)
Failures:
1) Recurring scheduling next pending automations with monthly frequency doesn't fail to schedule if the current time is within subsecond of the time component of start_date
Failure/Error:
expect(pending_automations.first.execute_at).to eq_time(
Time.parse("2023-11-05 07:30:00 UTC"),
)
2023-11-01 07:30:00 UTC is not within 1 millisecond of 2023-11-05 07:30:00 UTC
# ./plugins/automation/spec/triggers/recurring_spec.rb:167:in 'block (4 levels) in <main>'
2) Recurring when trigger is called every_month creates the next iteration one month later
Failure/Error:
expect(pending_automation.execute_at).to be_within_one_minute_of(
Time.parse("2021-07-02 08:00:00 UTC"),
)
2021-07-04 08:00:00 UTC is not within 1 minute of 2021-07-02 08:00:00 UTC
# ./plugins/automation/spec/triggers/recurring_spec.rb:408:in 'block (4 levels) in <main>'
Finished in 7.53 seconds (files took 5.78 seconds to load)
2 examples, 2 failures
Failed examples:
rspec ./plugins/automation/spec/triggers/recurring_spec.rb:149 # Recurring scheduling next pending automations with monthly frequency doesn't fail to schedule if the current time is within subsecond of the time component of start_date
rspec ./plugins/automation/spec/triggers/recurring_spec.rb:404 # Recurring when trigger is called every_month creates the next iteration one month later
```
should i be fixing these in my fork or letting the team/bot fix them instead?
isaac
May 13, 2026, 6:55pm
2
Thanks lilly for the back and forth there. A couple things
To interact with the bot you need to comment @patch-triage and then you can use plain english for your request. It’s functionality is currently limited at reviewing, suggesting changes, rebasing your PR, and creating a new commit with the suggested changes.
It will not commit changes on forks, however it can still review / suggest changes. I have just made changes to make that explicit, so you will need to handle any suggested changes yourself (as you have done).
If you would like to take full advantage of the bot I suggest creating a PR directly to core rather than through your fork
Let me know if that answers your questions!
Lilly
May 13, 2026, 7:10pm
3
thank you Isaac, that clears things up. i’m just so used to forking repos for PRs, but i’ll start doing PRs on core branches instead in cases like this - the triage bot seems pretty useful.
also, spec tests are the bane of my programming.
Lilly
May 13, 2026, 8:15pm
4
i don’t think i can do this anymore now that i am not staff though
isaac
May 13, 2026, 8:33pm
5
Ah… yes. You can still take advantage of:
I will raise the topic of allowing forks to have write access to the PR internally.
