Skip to content

feat: Invalidate cached signature on new signing request#199

Open
BranimirTomeljak wants to merge 6 commits into
mainfrom
feat/fill-error-outcomes
Open

feat: Invalidate cached signature on new signing request#199
BranimirTomeljak wants to merge 6 commits into
mainfrom
feat/fill-error-outcomes

Conversation

@BranimirTomeljak

@BranimirTomeljak BranimirTomeljak commented Jul 17, 2026

Copy link
Copy Markdown
Collaborator

Description

A requeued borrow fill signs a fresh deadline each attempt, but the MPC signature cache was keyed by chain and deposit id only. The retry's status subscription returned the first attempt's cached signature, which no longer matched the new request.

  • HandleSigning removes the cached signature for the deposit before dispatching the new signing request, so the status stream waits for the fresh round instead of serving the stale signature.
  • Removal uses each protocol's session key.

Related Issue Or Context

Closes: #

How Has This Been Tested? Testing details.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation

Checklist:

  • I have commented my code, particularly in hard-to-understand areas.
  • I have ensured that all acceptance criteria (or expected behavior) from issue are met
  • I have updated the documentation locally and in docs.
  • I have added tests to cover my changes.
  • I have ensured that all the checks are passing and green, I've signed the CLA bot

@github-actions

Copy link
Copy Markdown

Go Test coverage is 37.1 %\ ✨ ✨ ✨

@github-actions

Copy link
Copy Markdown

Go Test coverage is 37.3 %\ ✨ ✨ ✨

@github-actions

Copy link
Copy Markdown

Go Test coverage is 37.2 %\ ✨ ✨ ✨

@mpetrun5 mpetrun5 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I think it is better to invalidate the old signature and remove it from cache so it is not returned until the new one is generated.

@BranimirTomeljak BranimirTomeljak changed the title feat: Key the across signature cache by the borrow digest feat: Invalidate cached signature on new signing request Jul 20, 2026
@github-actions

Copy link
Copy Markdown

Go Test coverage is 36.9 %\ ✨ ✨ ✨

@github-actions

Copy link
Copy Markdown

Go Test coverage is 36.9 %\ ✨ ✨ ✨

@BranimirTomeljak
BranimirTomeljak marked this pull request as ready for review July 20, 2026 13:41
s.Equal(http.StatusBadRequest, recorder.Code)
}

func (s *SigningHandlerTestSuite) Test_HandleSigning_ErrorHandlingMessage() {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Why are these tests deleted instead of just adding a new test?

Comment thread api/handlers/signing.go
return nil
}

func sessionKey(protocol ProtocolType, chainID uint64, depositID string) string {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Can we move this function somewhere?
Maybe under TSS signing and reuse it the protocol handlers so it is consistent.

@github-actions

Copy link
Copy Markdown

Go Test coverage is 36.9 %\ ✨ ✨ ✨

@BranimirTomeljak
BranimirTomeljak marked this pull request as draft July 20, 2026 14:32
@BranimirTomeljak
BranimirTomeljak marked this pull request as ready for review July 20, 2026 14:34
@mpetrunic

Copy link
Copy Markdown
Member

Out of curiosity, why not store deadline along with signature and return cached if it's still valid (deadline hasn't passed)?

@mpetrun5

mpetrun5 commented Jul 20, 2026

Copy link
Copy Markdown
Collaborator

Out of curiosity, why not store deadline along with signature and return cached if it's still valid (deadline hasn't passed)?

It would have to be a breaking change and I would like to avoid that because you would need to ask for a specific nonce/deadline signature pair instead of just sending the ID of the order (could be done if some logic to track and expire deadlines is added so you either get that one or generate a new one).
It would need a lot of changes just because signature and deadline are part of the hash so you would need to separately also send them everywhere.
IMO, this is cleaner.

This is more of an edge case when someone calls this twice for the same order (probably because the first try failed) which shouldn't even happen as the solver can just keep the first signature if it is in a hurry.

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.

3 participants