Skip to content

Comments

Lock file maintenance#1899

Open
renovate[bot] wants to merge 26 commits intomainfrom
renovate/lock-file-maintenance
Open

Lock file maintenance#1899
renovate[bot] wants to merge 26 commits intomainfrom
renovate/lock-file-maintenance

Conversation

@renovate
Copy link
Contributor

@renovate renovate bot commented Feb 5, 2026

This PR contains the following updates:

Update Change
lockFileMaintenance All locks refreshed

🔧 This Pull Request updates lock files to use the latest dependency versions.


Configuration

📅 Schedule: Branch creation - "before 4am on monday" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot requested a review from a team as a code owner February 5, 2026 11:26
@renovate renovate bot enabled auto-merge (squash) February 5, 2026 11:26
@renovate renovate bot force-pushed the renovate/lock-file-maintenance branch from dcf4e8b to 0ac00d7 Compare February 5, 2026 11:53
@renovate renovate bot force-pushed the renovate/lock-file-maintenance branch from 0ac00d7 to b23716b Compare February 5, 2026 11:59
@renovate
Copy link
Contributor Author

renovate bot commented Feb 5, 2026

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.

@codecov
Copy link

codecov bot commented Feb 9, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.04%. Comparing base (fa22fd0) to head (7ba8c48).

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1899   +/-   ##
=======================================
  Coverage   99.04%   99.04%           
=======================================
  Files         306      306           
  Lines       11590    11593    +3     
=======================================
+ Hits        11479    11482    +3     
  Misses        111      111           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@rtuck99
Copy link
Contributor

rtuck99 commented Feb 9, 2026

@Relm-Arrowny I have made a change to apple2_undulator such that the wait=False on the sets are no longer present, however if left as is the await asyncio.gather() would wait for them to complete.

As presumably this is not what was intended, I have merged the subsequent wait_for_value() into the same gather() operation. Please can you check and see if this is indeed what you intended

@Relm-Arrowny
Copy link
Contributor

@Relm-Arrowny I have made a change to apple2_undulator such that the wait=False on the sets are no longer present, however if left as is the await asyncio.gather() would wait for them to complete.

As presumably this is not what was intended, I have merged the subsequent wait_for_value() into the same gather() operation. Please can you check and see if this is indeed what you intended

Do we have to change it, I do not remember if it has to be wait = False or not I am 50% sure it has to as setting it to False is an active choose as the default is Ture.
If we have to change it i can try testing this change when hardware is avaiable.

Copy link
Contributor

@DominicOram DominicOram left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I will make the first suggested change and happy to do the 2nd if @Relm-Arrowny agrees.

# discard the current value (OK) so we can await a subsequent change
await anext(demand_accepted_iterator)
set_status = setpoint_v.set(value, wait=False)
set_status = setpoint_v.set(value)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should: As discussed, I think we could change the signal to be wait=False

Comment on lines +401 to +409
async def initiate_moves():
await asyncio.gather(
self.gap().set_move.set(value=1, timeout=timeout),
self.phase().set_move.set(value=1, timeout=timeout),
)
LOGGER.info("Gap and phase set_move()s completed.")

# assign the task to prevent GC killing it
self._move_task = asyncio.create_task(initiate_moves())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have to change it, I do not remember if it has to be wait = False or not I am 50% sure it has to as setting it to False is an active choose as the default is Ture.
If we have to change it i can try testing this change when hardware is avaiable.

Should: @Relm-Arrowny We need to change it so that we can use the latest ophyd-async (https://github.com/bluesky/ophyd-async/releases/tag/v0.15). I don't see why you would need to not wait here when there are other bits of the code where you are waiting and if you're not sure either way can I suggest we:

  • Change it to wait=True
  • Make a new issue to test ASAP - I am happy to come down to the beamline and help with this too, if there is weird EPICS behaviour we can probably also ask @coretl

If we can definitely do this test next week then maybe we can wait until then to merge but we're now 2 ophyd-async versions behind so I would like to move ASAP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants