-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: from-org refactor #1296
fix: from-org refactor #1296
Conversation
private connection: Connection; | ||
private registry: RegistryAccess; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could be readonly
if we want to
// The 'singleRecordQuery' method was having connection errors, using `retry` resolves this | ||
// Note that this type of connection retry logic may someday be added to jsforce v2 | ||
// Once that happens this logic could be reverted |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice
frequency: Duration.milliseconds(1000), | ||
timeout: Duration.minutes(3), | ||
poll: async (): Promise<StatusResult> => { | ||
const res = ensureArray(await this.connection.metadata.list(query)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have our connections just become more resilient to remove this polling? I don't understand why we're doing this to begin with
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, part of the jsforce stuff that Cristian did jsforce/jsforce#1407.
I think the retry logic was using pollingClient to work around those network issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@WillieRuemmele Shane is correct, I added the pollingClient logic here:
#941
jsforce retries on the same errors that pollingClient and more.
QA Notes
before: sf project generate manifest --from-org test-9flhyhvfmlba@example.com
› Warning: @salesforce/cli update available from 2.36.8 to 2.37.4.
Error (1): _Default: Could not infer a metadata type
Try this:
Additional suggestions:
Confirm the file name, extension, and directory names are correct. Validate against the registry at:
<https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json>
If the type is not listed in the registry, check that it has Metadata API support via the Metadata Coverage Report:
<https://developer.salesforce.com/docs/metadata-coverage>
If the type is available via Metadata API but not in the registry
- Open an issue <https://github.com/forcedotcom/cli/issues>
- Add the type via PR. Instructions: <https://github.com/forcedotcom/source-deploy-retrieve/blob/main/contributing/metadata.md> ✅ : after ➜ ../../oss/plugin-deploy-retrieve/bin/run.js project generate manifest --from-org test-9flhyhvfmlba@example.com
Warning: _Default: Could not infer a metadata type
successfully wrote package.xml NOTE: |
What does this PR do?
What issues does this PR fix or reference?
forcedotcom/cli#2841
@W-15584672@