508 response codes use 'active slot' instead of 'slotId'

[sphlabs]

• I'm submitting a ...
  [X] bug report
  [ ] feature request
  [ ] question about the decisions made in the repository
  [ ] question about how to use this project

• Summary
  If a slot change is initiated by the slot select command, the 508 response message that is returned uses the id active slot rather than slotId to identify the slot. Currently only slotId is being matched and passed up the chain.

The transport async handler needs to recognise active slot and pass it up as slotId

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. StackOverflow, personal fork, etc.)

[mint-dewit]

Do you know if this is an issue in all firmware versions or did it change in one of the newer versions?

[sphlabs]

Do you mean the Hyperdeck firmware API? I’m not sure, but possibly. I discovered this while trying to work out why companion slot change commands were not updating the variable (which used to work). This is a different response to the one generated when pulling a drive. It also isn’t mentioned anywhere in the API docs…

…

On 16 Feb 2021, at 06:49, Balte de Wit ***@***.***> wrote:  Do you know if this is an issue in all firmware versions or did it change in one of the newer versions? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[mint-dewit]

I actually stumbled upon a device with API v1.3 earlier today and it had the same response so I don't think this is recent, when you pull a drive does it send a slot id instead or is that not even a transport info? (I only have remote access so can't pull drives myself)

I think I'll put in a fix for this while doing the v1.11 work

[sphlabs]

From my logs, it looks like a 508 `transport info` returns `active slot` but a 208 code returns `slot id`. According to the docs a 508 (async) should return the same parameters as a 208 (requested). That does not seem to be the case…

…

On 16 Feb 2021, at 16:26, Balte de Wit ***@***.***> wrote: I actually stumbled upon a device with API v1.3 earlier today and it had the same response so I don't think this is recent, when you pull a drive does it send a slot id instead or is that not even a transport info? (I only have remote access so can't pull drives myself) I think I'll put in a fix for this while doing the v1.11 work — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALD6KYOJ2Q66QIBL7TA3R4LS7KMELANCNFSM4XVMTPAA>.

[mint-dewit]

Yes, that's also what I'm seeing and the 208 is probably what the initial implementation was based on, I just wondered if it was ever possible to get a 508 in combination with a slot id or if it is only active slot. Because in the first case I need to handle both cases but in the latter case I can just change the parameter name in the deserialization

[sphlabs]

That’s the bit I’m not sure about — if there are situations where a 508 will return `slot id` — given that the docs don’t mention `active slot` at all…

…

On 16 Feb 2021, at 18:23, Balte de Wit ***@***.***> wrote: Yes, that's also what I'm seeing and the 208 is probably what the initial implementation was based on, I just wondered if it was ever possible to get a 508 in combination with a slot id or if it is only active slot. Because in the first case I need to handle both cases but in the latter case I can just change the parameter name in the deserialization — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALD6KYNPPQG472IO2JNMP2TS7KZ23ANCNFSM4XVMTPAA>.