lorawan-stack: Sending gateway PUT request with empty diff results in an error

Summary

When being in entity general settings, we allow submitting PUT requests with no changes for applications. Currently submitting the same PUT request with empty payload for gateways results in a backend error:

Steps to Reproduce

  1. Submit a request with to http://localhost:1885/api/v3/gateways/<gateway_id> with request payload {"gateway":{},"field_mask":{"paths":[]}}
  2. Observe the error returned

What do you see now?

{
  "code": 3,
  "message": "error:pkg/errors:validation (invalid `gateway`: embedded message failed validation)",
  "details": [
    {
      "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
      "namespace": "pkg/errors",
      "name": "validation",
      "message_format": "invalid `{field}`: {reason}",
      "attributes": {
        "field": "gateway",
        "name": "UpdateGatewayRequestValidationError",
        "reason": "embedded message failed validation"
      },
      "correlation_id": "27e3f23d15f946f5a0e32d3988310944",
      "cause": {
        "namespace": "pkg/errors",
        "name": "validation",
        "message_format": "invalid `{field}`: {reason}",
        "attributes": {
          "field": "version_ids",
          "name": "GatewayValidationError",
          "reason": "embedded message failed validation"
        },
        "cause": {
          "namespace": "pkg/errors",
          "name": "validation",
          "message_format": "invalid `{field}`: {reason}",
          "attributes": {
            "field": "model_id",
            "name": "GatewayVersionIdentifiersValidationError",
            "reason": "value does not match regex pattern \"^[a-z0-9](?:[-]?[a-z0-9]){2,}$\""
          },
          "code": 3
        },
        "code": 3
      },
      "code": 3
    }
  ]
}

What do you want to see instead?

Success like with submitting exactly the same payload for application PUT request

Environment

  • v3.10.0-rc1

How do you propose to implement this?

Don’t know exactly

How do you propose to test this?

Testing in console

Can you do this yourself and submit a Pull Request?

I think that would take too much time

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 16 (16 by maintainers)

Most upvoted comments

another solution would be to disable the submit button if no fields are changed, which sounds like a way simpler fix, that is also satisfying UX requirements

This seems like the best approach then.

Requiring a field mask is allowed by the specification:

Note that in the presence of schema evolution, this may mean that fields the client does not know and has therefore not filled into the request will be reset to their default. If this is unwanted behavior, a specific service may require a client to always specify a field mask, producing an error if not.

@htdvisser and could lead to unexpected results when we add fields in newer versions, while a client remains at an old version, and may unintentionally zero out a field by supplying it in the “body” with an empty field mask.

If the field mask is empty, the value should not be taken from the body, right?

I think that supplying an empty field mask should be a no-op on update. It could be used by clients to ensure the entity exists and/or that there’s valid auth to make an actual change.

The issue reported by @pgalic96 seems to be that we require certain fields on PUT, but I don’t think that we should be doing that.