After deploying a single field updating OST takes ~20-30 seconds before next deploy can happen.

[Justin Julicher]

So the process is I just save a field and it deploys that to the sandbox. It then updates the OST for about 30 seconds - it seems this is a long time for a single field update?

Are doing stuff around updating metadata lists for connections so this might be a moot point at this stage?

Anyway I’ve turned on OST logging (not trace - let me know if you want that), added a CPU profile as well. There was no freeze so no thread dumps.

Let me know if you want anything else

‌

[Justin Julicher]

Here is the OST for the project too.

[Justin Julicher]

Oh and I have disabled it for now but would rather have it enabled.

‌

[Scott Wells]

Justin, the 30 second gap appears to be here:

2022-08-22 12:14:57,935 [10113117]   INFO - #c.i.i.b.ForceComBuilder - Regenerating the OST entries for { amc__Project__c }.
2022-08-22 12:14:58,507 [10113689]   WARN - #c.i.s.OfflineSymbolTable - Failed to read custom field XML file C:/Users/justinj/Workspace/RealEstateSystemsSalesforce/force-app/main/default/objects/ContractDetail__c/fields/ContractCode__c.field-meta.xml: Unexpected character '?' (code 63) in prolog
 at [row,col {unknown-source}]: [1,2]
?????
2022-08-22 12:15:27,773 [10142955]   FINE - #c.i.s.OfflineSymbolTable - Listing custom fields to help partition SObject type loading.

All that's happening in between those lines is a series of API calls to get SObject/field info from the org. I'd need a trace-level log to see more of the timing, but at a glance it looks like it's just slow API response time from the org itself. Feel free to get a trace-level log and attach it. As such a log may roll due to verbosity, please make sure to include the full OST generation.

[Justin Julicher]

Ok, so what I’m wondering is there any way you can queue these up so that if I have to deploy field A then B then C it’s not going to go Deploy A - Update OST - Deploy B - Update OST - Deploy C - Update C, which takes upwards of 90 seconds to complete. Would you be able to have a separate queue for the updating of the OST that doesn’t prevent subsequent deploys? So it would go more like:

Deploy A → Deploy B → Deploy C

Update OST → Update OST → Update OST

That way the slow API wont affect dev workflow so much.

I’m also curious as to the need for an API call when deploying a field as wouldn’t all the information to update it be in the file? Do you regenerate the whole file rather than just updating the single field in the OST?

‌

‌

[Scott Wells]

Sounds like you're talking about a very specific scenario where you're deploying multiple fields one-at-a-time in quick succession, no? I'm just curious, but is there a reason that those are deployed in isolation of one another? I'm guessing you're just moving between tabs that you know need to be deployed and using deploy-on-save, no?

Regarding auto-update of the OST after a successful deployment of SObjects/fields, I've actually considered just removing that and instead providing a notification that the OST may be out of date. Not just for SObjects/fields, but in a broader sense. I'd like to have IC2 check last modified timestamps of the types of metadata it uses to construct the OST--SObjects, fields, Apex classes, custom labels, etc.--and if things are newer in the org than the last OST generation, gently inform the user that an OST update might be in order. That would, of course, be optional, and perhaps that current option to update the OST would become three-state with on, off, and prompt, and I'd make prompt the default. The reason, of course, is exactly what you've brought up here. That OST update can be disruptive to rapid edit/deploy/edit/deploy/etc.-type workflow, but it's also good to know when the OST might need some updates. I've also thought about adding a quick fix for an unresolvable SObject type/field to regenerate the OST, especially if I can tell from the local project files that those are definitely for SObject type/field names.

I'm pretty sure that's the route I'll end up going to resolve this overall issue as it also helps with the other general class of issues around stale OSTs.

Now having said that, I wouldn't expect the APIs that IC2 needs to call to update a single SObject to take 30 seconds, so I would love to see a trace-level log of it doing so to properly understand what's taking so much time.

[Scott Wells]

Issue tracker grooming. If this is still an issue, please feel free to reopen, ideally with a concrete reproduction scenario.