Bug: type of FileAttachment.contentBytes should be string instead of number

[abdulkareemnalband]

Bug

Type of FileAttachment.contentBytes should be string instead of number

in

msgraph-typescript-typings/microsoft-graph.d.ts

Line 1920 in 33025e1

contentBytes?: number

AB#7041

[muthurathinam]

@abdulkareemnalband Thank you for reporting. will look into this and get back to you.
883193

[darrelmiller]

@muthurathinam This is declared as <Property Name="contentBytes" Type="Edm.Binary"/>. What do we normally use for mapping to Binary type? Can we use a byte array?

[bamncan]

Verifying that sending this property in as a base64 encoded string is what is accepted by the API.

let attachment: any = {
  '@odata.type': '#microsoft.graph.fileAttachment',
  contentBytes: Buffer.from('attachment').toString('base64'),
  contentType: 'text/plain',
  name: 'attachment.txt',
  size: 10
}

or

contentBytes: 'YXR0YWNobWVudA==',

Either will be accepted by the API when adding the attachment.

[RobvH]

This issue is still present and I've submitted a PR to correct the mistake. In the PR I link to the documentation and describe that it contains a contradiction that caused this error in the first place. In short, the type is not Edm.Binary in transmission, as the description accurately states, it is the "The base64-encoded contents of the file." Base64 encoding, by definition generates a string.

The impact of this bug is forcing test authors to cast through unknown to allow Typescript to ignore the contradiction between the incorrect type and actual API responses used as test fixtures; nullifying much of the value of the type in the first place.

Thanks for all your hard work and efforts on this and I hope this PR helps! ❤️

[RobvH]

I also raised this issue with the Docs project here: https://github.com/microsoftgraph/microsoft-graph-docs-contrib/issues/1972

[RobvH]

The fix was made upstream and the corrected types are in PR microsoftgraph/microsoft-graph-docs#328

❤️ Thanks to everyone who helped with this!