VLAN deletion fails silently

[EricPerl]

I feel ignored 😉

The absence of the UUID in the config is clearly a bug.
The creation of a UUID on the fly might self-correct the issue but only IF the UUID is added to the config (dicey on an enumeration or search).
Circling back to status codes, 404 was likely the appropriate code because whatever ID was used obviously did not match any resource.

You should be able to find the operation that "corrupted" the configuration by looking at the history.
Hopefully you didn't mess that up when you edited in the config file by hand.
The backup folder contains previous versions of the config file, apparently ordered by timestamps.
In the GUI, you can compare versions in System > Configuration > History.

[patient0]

I feel ignored 😉

The absence of the UUID in the config is clearly a bug.
...
Circling back to status codes, 404 was likely the appropriate code because whatever ID was used obviously did not match any resource.
UI, you can compare versions in System > Configuration > History.

You're now acknowledged, young Padawan :)

Of course I'm with you as in that it is a bug. For it to be reported I guess it would be helpful to know the current OPNsense version and if possible get an idea of the upgrade path taken (e.g. "started with OPNsense 1 in 1889 and went from there" :) ) and best the full config file (minus all privacy sensitive data). Somewhere along the upgrades the UUIDs should have been added but wasn't.

[ripdog]

Thanks for the help, all. I can confirm that adding a UUID to the VLAN in config.xml and reconfiguring fixed my issue.

I can only assume that the age of my VLAN, remaining untouched for multiple main version upgrades of Opnsense caused it to never receive a UUID at all. I suppose I should file a bug, now... sigh.

I feel ignored 😉

I'm sorry, but I didn't see anything in your post which required a reply. It was obvious from the beginning that UUIDs were used to identify the VLANs, as all API methods were referencing UUIDs - the issue being that the UUID for my VLAN changed every time it was retrieved.

I think I missed an apply. I suspect the same could happen the other way (deletion fails because the assignment is still present).

I had no reason to believe any of this applied to me. I had a fully functioning VLAN for years, I obviously didn't miss clicking apply. And my VLAN was not assigned.

You should be able to find the operation that "corrupted" the configuration by looking at the history.
Hopefully you didn't mess that up when you edited in the config file by hand.

I have never edited my config file before today. Hell, I had to ask in this thread where it was!

My oldest backup has my vlan in its current state - that is, without a UUID. It was from 6 April 2023.

Btw, what version OPNsense are you running, my test was on 25.7.a_36.

OPNsense 25.1.1-amd64.

For it to be reported I guess it would be helpful to know the current OPNsense version and if possible get an idea of the upgrade path taken (e.g. "started with OPNsense 1 in 1889 and went from there" :) ) and best the full config file (minus all privacy sensitive data). Somewhere along the upgrades the UUIDs should have been added but wasn't.

I'm afraid I haven't the foggiest when I installed Opnsense. I'd guest 2022...? But I've at least run this install through the last 3-4 major versions.

The config file is huge, I wouldn't feel comfortable sharing it publicly even if I had tried to clean it up.

[patient0]

The config file is huge, I wouldn't feel comfortable sharing it publicly even if I had tried to clean it up.

That is fair enough, I can understand.

When I get time this week I'll try to install a version from 3 or 4 years back. I assume it to be reproducible that way, as long as a VLAN without an UUID is created.

[patient0]

I'm afraid I haven't the foggiest when I installed Opnsense. I'd guest 2022...? But I've at least run this install through the last 3-4 major versions.

Btw, was is usually your upgrade path? Upgrade through OPNsense itself or reinstall from scratch and import the config file?

[EricPerl]

The wink emoji was a clue that this was kind of a joke (the being ignored part).

This said,

Just looking at the config file, VLANs are identified by UUIDs.
It would make sense for low-level operations on VLANs (search, enumerations, edit, delete...) to use these UUIDs.

Was my way of enticing the OP to look at the config file and compare UUIDs there with the ones used in the API calls.
The absence of UUID was fatal.

Some of the rest was conjecture based on lack of context...

If the oldest backup already has a corrupt entry, I'm not entirely where a bug report about that part would go.
It's clearly the source of the issue.

A bug to handle the resulting situation more gracefully might have a better chance for a fix (more resilience).
It's easy to reproduce!

[franco]

Sorry, I didn't see this earlier but I think most has been said.

To explain how this can happen... it doesn't except that I think I know when this may have occurred:

> community/22.1/22.1.4:o interfaces: VLAN MVC conversion with API and QinQ support

22.1.4 added the UUID use for MVC use, but for a while there was a bug in the console that did not add the UUID for a newly created VLAN item until:

> community/22.7/22.7.7:o console: store UUID for VLAN device

That means that 22.7 images in particular exhibited this problem, which would be my guess when this install was first set up?


Cheers,
Franco