Rename IncomingFile.web_url to content_url - #580
Merged
Conversation
The value arrives on the wire as the attachment's `content_url`, and `Attachment.content_url` already exposes it publicly, so the same value had two public names depending on which door a developer came through. Renaming now is free: the files feature has never been published. Matches the equivalent rename in teams.ts so the SDKs stay parallel. Also documents the trap the name invites: this URL is browsable, not fetchable. Bytes come from `download_url`. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 7d326e8a-aeb4-4481-bc0a-58d2a012584e
Contributor
There was a problem hiding this comment.
Pull request overview
This PR renames the IncomingFile public property from web_url to content_url to match the Bot Framework/attachment wire field name and align terminology with Attachment.content_url already exposed in the SDK.
Changes:
- Renamed
IncomingFile.web_url→IncomingFile.content_urland updated constructor/assignment accordingly. - Updated
FilesAccessormapping to populateIncomingFile.content_urlfromAttachment.content_url. - Updated the
FilesAccessorunit test to assert oncontent_url.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| packages/apps/tests/test_files_accessor.py | Updates assertions to validate content_url is mapped onto IncomingFile. |
| packages/apps/src/microsoft_teams/apps/files/incoming_file.py | Renames the public attribute/constructor parameter to content_url and updates the docstring warning about download behavior. |
| packages/apps/src/microsoft_teams/apps/files/files_accessor.py | Updates the attachment→IncomingFile mapping to use content_url and revises the explanatory comment. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
The docstring told callers bytes come from `download_url`, but that value is stored as `_download_url`, so the guidance named something a consumer cannot reach. Points at `download()` and `stream()` instead. Matches the same correction in teams.ts and teams.net. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 7d326e8a-aeb4-4481-bc0a-58d2a012584e
Kavin (singhk97)
approved these changes
Aug 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Renames the public
IncomingFile.web_urlproperty tocontent_url.This is not a breaking change
The property has never been published.
web_urlarrived with the "Receive files in personal scope" work and no release has been cut since, so there are no consumers to break in any published form.This is also the last cheap moment: once the files feature ships, the name is locked.
Why
The value arrives on the wire as the attachment's
content_url, andAttachment.content_urlalready exposes it publicly in this same SDK. That left the same value reachable under two different public names depending on which door you came through:Upstream doesn't call it a "web URL" either. APX sources it from
fileInfo.ObjectUrland writes it into the Bot Framework attachment'sContentUrlslot, soweb_urlwas a name this SDK invented at the boundary. The mapping comment infiles_accessor.pywas the only thing holding the two vocabularies together, and it's now unnecessary: the value is a straight pass-through.The one real objection, and how it's handled
content_urlsits next todownload_url, and it is the one that does not return content. That's a genuine footgun, but it already exists onAttachment.content_urlregardless of what we do here, and it's a docs problem rather than a design problem. Two public names for one value is the design problem. So the docstring now states the trap directly:Cross-SDK
Companion to microsoft/teams.ts#773 (
webUrl→contentUrl), with a matching PR forteams.net(WebUrl→ContentUrl). The feature is unreleased in all three, so all three can move together. Published docs inteams-sdkare updated separately.Validation
598 tests pass;
poe checkclean.