Recreating Tables Bug - Won't be fixed....

[klh]

So recently we have been transferring everything from an older version of ServiceNow to a new Jakarta instance.

I came across a pretty annoying bug. In summary, when you create a table and realise you did something wrong so delete it, you then can't recreate it properly with the same name as there is a problem with the way the delete works.

The response I got for a HI ticket for this was:

I have completed my investigation to this incident. Here is a summary of my findings;
Issue: For deleted tables that extend configuration item table, recreating them shows erratic behaviour. 
Behaviour 1, when the table is recreated, the field label is not created alongside. The field label now shows as Configuration item rather than the table field label. We can manually add a field label. 
Behaviour 2, on recreation of the table, we do not see the inherited fields on sys_db_object. Navigating to the table though shows the field 
Behaviour 3, Custom Fields created on the table before the deletion are not properly dropped. They do not exist on sys_dictionary but exist on sys_storage_alias and can be added to a list view. 
Most Probable Cause: PRB1189467 - Recreation of custom cmdb_ci extended tables after their deletion fails.
Solution Proposed: After carefully considering the severity and frequency of the issue, and the cost and risk of attempting a fix, it has been decided to not address PRB1189467 in any current or future releases. We do not make this decision lightly, and we apologize for any inconvenience. 
Workaround: The workaround here will be to raise a support incident for us to do a manual cleanup of leftover schema metadata in sys_storage_alias, sys_storage_table_alias, sys_dictionary, and sys_db_object after the delete.
Next steps: As we have a clear path to relief, I will place this incident in a Solution Proposed state. From our last call, I understood you have a number of affected records at this time. I would recommend you take some time to review this information and provide us with a list of all tables and columns currently affected and we will do the cleanup for you as soon as we receive this.

Now correct me if I am wrong, but this isn't the right approach I think. It's a clear bug and the work around involves a manual process within your active instance by ServiceNow. Sure it will fix the issue for us, but we can't be the only people who have encountered this problem, and to say that it won't be addressed in "any current or future releases" doesn't actually inspire me with confidence. What else is lurking under the hood that won't be fixed?

Frankly it's making me worry about doing anything in the platform if something as core as deleting a table isn't handled properly as I can't imagine something like this passing UAT in any systems I have developed.

Does anyone else have any thoughts on this?

[Dave Smith1]

It appears even as admin, you don't have the ability to delete those. This was confirmed as expected behaviour by the ServiceNow rep. It's probably sensible for everyone not to have access to delete on those records, as you might cause some major stability issues if you could remove things from sys_storage_alias. 

Ouch.   But yeah, I can see the reasoning behind that.

What I am a bit more worried about if we could script out a nice cleanup tool, is that we don't quite know if we will catch everything. That would be even if we did have access to delete them.

Since there's no access levels, the point is moot... but really it shouldn't be difficult to walk table relationships and identify which objects belong to a specific table, then surgically zap them.   Essentially this is.. well, what SHOULD happen in the first place when a table is deleted!