Do we need to explain why 30?

I'll just provide some context in this reply: we decided to only show users jobs from up to 30 days ago because on our backend we only store jobs and artifacts for up to 30 days. This way we align with that storage policy.

Can we just explain this for context?

Using TransformationHubViewProvider.instance here to construct the instance implements the singleton pattern and ensures that only one instance exists throughout. That way, when TransformationHubViewProvider.instance is referenced in different parts of the code, we get the same instance every time. I was having issues with accessing the instance with the way it was constructed previously since there seemed to be two instances that existed at the same time.

Can we just add some context to the PR why we are getting rid of these so reviewers are aware?

We decided to remove the stopJob() call because with the introduction of the refresh functionality, users can actually resume their jobs within 12 hours. This call was initially added so that jobs that were interrupted on client side would not just run till they time out on the backend. However, with this feature, since users can now continue their jobs, stopping the job on the backend would prevent users from taking this action.

Just curious, are there other examples of us returning script tags within HTML?

There are a few that I can see: showPlanProgress() method in TransformationHubViewProvider.ts, getWebviewContent() method in webViewPanel.ts -- this one uses it similarly to how I have done so here --, and getHtml() method in referenceLogViewProvider.ts

Is this the same folder as where the QCT CLI stores artifacts?

No, the CLI stores artifacts in .aws/qcodetransform/ (specifically within the transformation_projects subdirectory)

Instead of checking the job status to delete these files, just check if fs.existsSync() to determine whether or not to delete the files

The reason I was thinking of using status as the check here is because if the job fails or is incomplete on client side, we do not want to delete the metadata file and zip copy since those are needed to resume the job. Is there a better way to do this check?

Sidenote: I will be moving the original zip deletion (lines 757-760) outside of this if clause since that can be deleted regardless

How is FAILED_BE managed? We already have FAILED so wondering if we need this

I added FAILED_BE for the case where a job actually fails on the backend, though users will still only see it show up as FAILED in the Transformation Hub. In such a case we do not want users to be able to refresh that job because there are no updates for it on the backend. I had to add this local status because when checking for any jobs that may need to be resumed, I search for a status of FAILED in the local transformation history file (since this is the status that shows up on the frontend in the case of a client-side failure, like a network disruption). We don't want to mislead users into thinking an actual failed job is still refreshable or "in progress," so this FAILED_BE status helps differentiate that. But it's only used in the context of the history file/table.

Perhaps there is a better way I could've done this?

what happens if they don't exist?

Nothing happens; since I'm using { force: true } here, no error is thrown even if the files don't exist