correct response pattern matching and add nil check

[dillinger]

While trying out Nosedrum for the first time, I encountered the following error:

23:03:35.535 [error] Error in event handler: ** (WithClauseError) no with clause matching: {:ok}
    (nosedrum 0.6.0) lib/nosedrum/storage/dispatcher.ex:60: anonymous fn/1 in Nosedrum.Storage.Dispatcher.handle_interaction/2
    (seastar_bot 0.1.0) deps/nostrum/lib/nostrum/consumer.ex:448: anonymous fn/1 in SeastarBot.Consumer.handle_info/2
    (elixir 1.18.4) lib/task/supervised.ex:101: Task.Supervised.invoke_mfa/2
    

It turns out that in Nostrum v10, the API function Nostrum.Api.Interaction.create_response/2 returns {:ok} | {:error, reason}, which is not compatible with the current pattern matching in Nosedrum.Storage.Dispatcher that expects :ok <- Storage.respond(interaction, response).

Additionally, there was a missing case handling for when Keyword.get(response, :type) returns nil inside Nosedrum.Storage.Dispatcher.handle_interaction/2.

Changes

• Updated handle_interaction/2, Nosedrum.Storage.respond/2, and Nosedrum.ComponentHandler.ETS.handle_component_interaction/2 to correctly pattern match the tuple {:ok, _} or {:error, _} returned by Nostrum v10 API functions.
• Added handling for the case when response[:type] is nil to avoid potential crashes.

Interestingly, in Nostrum v11, it was refactored so, the API responses now use one format across the board, all functions consistently return either :ok | Nostrum.Api.error().

[jchristgit]

Thank you for the PR!
Since the master branch is informally meant for nostrum's latest master, I suggest we drop the matching for {:ok} and update Dispatcher.handle_interaction to return :ok instead of {:ok}. I would then update mix.exs to point to nostrum's master (currently it points to the release) and later, when a new nostrum release is made, make a new nosedrum release. What do you think?

[dillinger]

Thanks for the review!
That sounds like a better approach. Makes sense to align with Nostrum v11.
I'll update the PR to revert all changes related to {:ok}. What about the is_nil(res_type) check do you think that makes sense to keep?

[jchristgit]

Yes, the is_nil check definitely makes sense :-)