ServiceNow Studio just deleted a file instead of saving - no logs no ability to recover - HELP!

[eddy42]

I have done a lot of work over the weekend on a script include in my scoped application.  I tend to work directly in the application file or the old studio - I HATE the new ServiceNow Studio.  However they keep encouraging me to use it.

This morning I used the new studio and on saving the script include (done it 20+ times by 9am) the file vanished.  I could see it in the files list in studio until I refreshed the page and it was gone.  I checked deleted records but they don't show in there it seems.  I checked the update set in the scoped app and the metadata is there (so I can thankfully capture the script) but on clicking 'Show related file' it shows 'record not found'.

Interestingly in the update set log it shows the last entry as INSERT/UPDATE to a script include that has no name, and the record is missing.  If I had deleted it, this would show the action as DELETE.

I have logged a support request but they take FOREVER to respond.  I have a deadline looming and was about an hour from completion.

My only option (I think) will be to XML export an older version from live, then import it (to retain the sys_id) and then manually update and save it.

Why would this happen - can anyone think of any other solution.  And should I EVER use the ServiceNow studio again?

[Vikram Reddy]

Hi @eddy42,

First, shelve the XML export/reimport plan for a second. Open that sys_update_xml record for the "no name" entry and read the payload field, it holds the full XML for the script include, script body included, so you can copy the code straight out of it right now.

On why the file vanished, I'd rather not invent internal mechanics, but two things are worth ruling out given how you described the issue:

• Source control stash: if this scoped app is linked to a Git repo through Studio, there's an open known error, KB0622655, about Studio losing changes to unsaved files during a stash operation. Check Source Control, Manage stashes on the app's details page, your script include may be sitting in a stash rather than actually gone
• Mixed editing surfaces: you worked the weekend directly in the file record or old Studio, then opened new Studio this morning. New Studio keeps its own client-side view of the file list, and switching surfaces mid-stream on the same file is a good way to get that view out of sync with what's actually on the record. Worth sticking to one editor per session going forward, that's a practitioner habit more than a documented rule

Either way, two things to do right now:

1. Pull the script text out of the sys_update_xml payload field and move on, don't wait on support for that piece
2. Add sys_script_include to the glide.ui.audit_deleted_tables property. Tables with a sys_ prefix are skipped by Deleted Records by default, which is exactly why your check came up empty regardless of what actually happened

Is the app source controlled, or is this purely instance update sets? That changes which of the two explanations above is actually worth chasing with support.

As for ever using new Studio again, I wouldn't swear it off over one bad morning, but I would stop treating it as interchangeable with the classic editor on the same file in the same working session.

Thank you,
Vikram Karety
Octigo Solutions INC

[eddy42]

Thanks for the detailed response.
The app, is source controlled, however no stash operations were happening (I'm the only person with permissions to it).
I had moved from one machine to another (two instances of the servicenow studio) but as I said, I'd saved many times before this morning without issue.  Even if they were out of sync, the worst that should happen is I save over an older version.

Yes, I can get the script so I am safe, I've not lost data.  BUT If I create a new script include now, it will not have the same sys_id as the one in live, this will cause issues for the app update process into live.

This seems like a major bug to me - even if you could argue that different sessions shouldn't be used, there is no restriction on this and no warning that major data loss could occur - considering I had hundreds of versions of that file, what did the instance do - delete all of them at once with no ability to restore - DANGEROUS.

[Vikram Reddy]

Hello @eddy42,

On "no stash, I'm the only one with permissions" - that doesn't actually rule out KB0622655. The bug isn't about a second person locking you out, it's a client cache going stale relative to the server. Two live Studio sessions from the same user on two machines against the same source-controlled app is basically the reproduction shape in that article, just with one person instead of two. Worth checking Source Control, Manage stashes anyway, but if it's empty, don't drop the theory, just note in your support ticket that it happened with a single user across two sessions, not two users, since that's a narrower and more useful repro for them than what the KB currently describes.

You're right that "out of sync" should mean "saved over an older version," not "record vanished." That gap, an overwrite turning into a delete, is the actual defect and the sharpest thing to push support on. Don't let them close this as "user error, working in two places" without an answer to that specific point.

On the sys_id problem, you don't need to touch live at all, and you don't need to retype anything. You already have the full final version sitting in that sys_update_xml record. The trick is getting the platform to reapply it as an insert instead of you rebuilding it by hand:

1. Open that sys_update_xml record (the "no name" one). Since the underlying script include is gone, you can't use the normal "edit, save, back out" trick to move it, so go to the list view and edit the Update Set field on that row directly, moving it into a fresh, empty local update set. Normally that's discouraged because it can orphan duplicate customizations elsewhere, but with no live record left to touch, it's the only option and it's safe here since you're isolating one orphaned entry.
2. Complete that update set, then use the Export to XML related link on the update set record itself (not a list export, that skips the wrapper tags you need).
3. Go to System Update Sets, Retrieved Update Sets, Import Update Set from XML, and upload the file.
4. Preview it. Since the target sys_script_include record doesn't exist, this should show as an insert rather than an update.
5. Commit.

Update sets create the record using the sys_id baked into the payload when the target doesn't already exist, that's just how apply has always worked, it's not special cross-instance behavior. So this should hand you back the same script include, same sys_id, with this morning's actual final script in it, no manual retyping and no risk of your live promotion tripping over a mismatched sys_id. I'd test this on a sub-prod clone or in a scratch app first if you have the option, purely to confirm the preview behaves as expected before you commit against your real record.

And yes, "hundreds of versions gone with no way back" is a fair way to describe what happened, not an overreaction. Version history is anchored to the record's sys_id, so once the base record itself is gone rather than soft-deleted, and sys_script_include sits outside glide.ui.audit_deleted_tables by default, that history has nothing left to hang off of. That's exactly why I'd have you add it to that property going forward, but it doesn't get this morning's history back. Worth saying plainly to support: this isn't "lost some edits," it's "lost the record's entire audit trail because the platform didn't consider it worth capturing a sys_ table deletion by default."

Thank you,
Vikram Karety
Octigo Solutions INC

[eddy42]

Yes thanks for this - very detailed and I will likely give your solution a try if support don't get back to me - 7hrs now and no response - as far as I can tell they haven't even read it.

I have no intention of letting them get away with 'a user problem' here.  This is unacceptable, and erodes confidence in the platform.

As I said in the original post I have captured the script (stored in safely in VS code) from the metadata - but if there is a platform bug, it is their responsibility to fix it and as far as possible provide a solution to me getting as much of my history back as possible.

I did push an update into TEST about a week ago, and I have all updates up to then in the repo on DevOps - but if I create a new record I will lost that history right...

The painful thing is having to go back to my management and delay their test phase because 'ServiceNow screwed up' - makes it sound like I missed the deadline and don't want to own up to it.  Also management aren't going to see ServiceNow as dependable as previously - and as I have 12 years experience with it that works against me too.  Not a good day... (Anyway, thanks for your suggestions)