fix(conversion): missing target file extension #50219
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
I discovered that, when working on the richdocuments file conversion provider, not all file conversion providers will be properly detected when searching for the correct file extension to assign the converted file. When no destination is provided, the filename will not include an extension (e.g.
doc.
instead ofdoc.pdf
); however, when a destination is provided, we do not append the extension since it is assumed the destination would include it (e.g./subfolder/doc.pdf
).The issue lies with the following bit of code, primarily:
If this method is called twice, the logic for getting a registration context to peek at the registered file conversion providers is skipped, and the preexisting providers are simply returned. This sounded like a good idea at first, but I ran into an issue where my richdocuments file conversion provider was not being returned in this list on subsequent calls to the method (maybe due to it not being fully registered yet or something?).
Removing the
if
statement seems to work and resolve the issue, but I think we can avoid having to call this method more than once anyway but changing the logic for getting the correct file extension. We already get the valid conversion provider that can do the conversion, so we just get the right extension from its supported ones instead of re-fetching all the registered providers.The tests implemented already never failed, and my guess for that is because the testing app's conversion providers are being registered first somehow before other the other apps' providers. /shrug
Checklist