extend state verification to open connection commands

Authored by sitter on Aug 28 2019, 3:12 PM.


  • open/seek/read/write: may not call finished (only error)
  • close: must reach finality (finished or error)
Test Plan

when trying to play from sftp in dragonplayer the broken slave implodes

Diff Detail

R241 KIO
No Linters Available
No Unit Test Coverage
Build Status
Buildable 15752
Build 15770: arc lint + arc unit
sitter created this revision.Aug 28 2019, 3:12 PM
Restricted Application added a project: Frameworks. · View Herald TranscriptAug 28 2019, 3:12 PM
Restricted Application added a subscriber: kde-frameworks-devel. · View Herald Transcript
sitter requested review of this revision.Aug 28 2019, 3:12 PM

I do wonder if maybe it would make sense to revise the verification system to be based off of a list of allowed/forbidden functions that may be called during a command.

e.g. for open the requirements are actually more complicated than this diff establishes. It should be: CMD_OPEN must result in exactly 1 opened() call OR exactly 1 error() call AND must not ever call finished(). This is a less specific variant of what m_finalityCommand represents. Where m_finalityCommand simply marks a command as allowed/forbidden to call error and finished, a more dynamic system would allow us to tightly control different calls.

Simply put: Any given command has 0:N functions it may or may not call. And currently we have no system to codify that.

So maybe something like this would make sense:

void validateCall(QString name)
q_assert(m_CurrentlyAllowedCalls.include?(name), "mustn't call this function");

void opened()

void finished()

[spam comment removed by sysadmin]

I've actually started work on a more general system for this. Will update soon.

sitter planned changes to this revision.Oct 21 2019, 2:56 PM
sitter abandoned this revision.Oct 23 2019, 12:45 PM

Replaced by D24887 which instead creates a more generic system to verify slave behavior.