Reusing EUIs of Deleted Gateways

[adamsondelacruz]

Summary

When you delete a gateway and then add a new one with the same EUI, if fails because it complains that the gateway already exists.

Steps to Reproduce

1. Remove an existing gateway
2. Add it using the CLI or
3. Add it using the API

What do you see now?

{
    "code": 6,
    "message": "error:pkg/identityserver/store:already_exists (entity already exists)",
    "details": [
        {
            "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
            "namespace": "pkg/identityserver/store",
            "name": "already_exists",
            "message_format": "entity already exists",
            "attributes": {
                "field": "gateway_eui",
                "value": "'3135313749005303'"
            },
            "correlation_id": "c0dc6bb73d714702bd8d0be57e83f369"
        }
    ]
}

What do you want to see instead?

Successfullly create the new gateway

Environment

amazon linux using TTN CLI and Postman using API Call

How do you propose to implement this?

When user try to insert a deleted gateway, update the deleted flag to false

Can you do this yourself and submit a Pull Request?

...

[htdvisser]

Related to #1121

[htdvisser]

I updated this issue a bit to have a slightly different scope than #1121, which we can make more about restoring deleted entities in general (instead of only applications).

In the current issue, let's focus more on adding new gateways with the same EUI as a deleted gateway.

[htdvisser]

Related to #604 (releasing IDs/EUIs)

[johanstokking]

@htdvisser even having #1703 (now in Next Up) is not entirely covering the common use case of being able to create a gateway with an EUI that has been used before. Looping in an administrator to purge an entity is not a nice user experience, plus purging an entity is more destructive than simply releasing the EUI.

Afaik we don't have security issues with releasing the EUI when deleting the gateway. It is optional already. It would, obviously, make recovery partial, i.e. the EUI is gone, but I think that is acceptable and also aligns with how device EUIs are released on deletion immediately.

Can we close this issue with simply releasing the EUI on gateway delete? If not, why not?

[htdvisser]

Yes, we could update the Gateway EUI field to nil/NULL on delete. Should be as simple as adding a

// AfterDelete releases the EUI of a Gateway after it is deleted.
func (gtw *Gateway) AfterDelete(db *gorm.DB) error {
	return db.Unscoped().Model(gtw).UpdateColumn("gateway_eui", nil).Error
}

in pkg/identityserver/store/hooks.go.

[johanstokking]

@bafonins can you pick this up?

[bafonins]

@adamsondelacruz please reopen if #1843 doesnt solve the issue.