Fix macOS dir behaviour by providing EINTR handling by Therzok · Pull Request #48694 · dotnet/runtime

Therzok · 2021-02-24T09:29:37Z

stephentoub

Might be worth adding a comment to the effect that EINTR isn't documented but has been shown to happen in practice. Otherwise, LGTM. Thanks for the fix.

Therzok · 2021-02-24T12:14:48Z

Added comments. I'm pretty sure readdir_r is being used on macOS, so I didn't guard readdir too.

akoeplinger · 2021-02-24T12:34:23Z

+ int error;
+
+ // EINTR isn't documented, happens in practice on macOS.
+ while ((error = readdir_r(dir, entry, &result)) && error == EINTR);


are you sure the EINTR is returned as the return value and not in errno?

I don't have a reliable repro, but I can look in xnu source. I can adapt it so it checks errno.

Seems like readdir_r sets the return value to whatever is in errno?

I've read a few man pages of different OSes and there seems to be little consistency regarding this.
If using errno works on macOS then I'd prefer that since it's what we use everywhere else.

I've changed it.

If using errno works on macOS then I'd prefer that since it's what we use everywhere else.
Except this API explicitly says errors are returned rather than surfacing through errno. Is there an example man page that says readdir_r sets errno? What happens if a readdir_r implementation doesn't touch errno at all, errno retains an EINTR value from prior to the readdir_r call, and readdir_r hits another error... might we end up in an infinite loop?

I can change the code back to checking the return code :D

Before you do, I'd like to hear from @akoeplinger :) I was actually asking questions rather than stating things that must happen ;-)

Specifically, on macOS/FreeBSD, it looks like this: https://opensource.apple.com/source/Libc/Libc-1439.40.11/gen/FreeBSD/readdir.c.auto.html

ghost · 2021-02-25T12:15:48Z

Hello @akoeplinger!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (`@msftbot`) and give me an instruction to get started! Learn more here.

akoeplinger · 2021-02-25T17:53:33Z

Test failures are due to #48751.

Therzok · 2021-02-24T09:29:37Z

Fixes#47584

Fixesdotnet#47584

stephentoub

Might be worth adding a comment to the effect that EINTR isn't documented but has been shown to happen in practice. Otherwise, LGTM. Thanks for the fix.

Therzok · 2021-02-24T12:14:48Z

Added comments. I'm pretty sure readdir_r is being used on macOS, so I didn't guard readdir too.

akoeplinger · 2021-02-24T12:34:23Z

+ int error;
+
+ // EINTR isn't documented, happens in practice on macOS.
+ while ((error = readdir_r(dir, entry, &result)) && error == EINTR);


are you sure the EINTR is returned as the return value and not in errno?

I don't have a reliable repro, but I can look in xnu source. I can adapt it so it checks errno.

Seems like readdir_r sets the return value to whatever is in errno?

I've read a few man pages of different OSes and there seems to be little consistency regarding this.
If using errno works on macOS then I'd prefer that since it's what we use everywhere else.

I've changed it.

If using errno works on macOS then I'd prefer that since it's what we use everywhere else.
Except this API explicitly says errors are returned rather than surfacing through errno. Is there an example man page that says readdir_r sets errno? What happens if a readdir_r implementation doesn't touch errno at all, errno retains an EINTR value from prior to the readdir_r call, and readdir_r hits another error... might we end up in an infinite loop?

I can change the code back to checking the return code :D

Before you do, I'd like to hear from @akoeplinger :) I was actually asking questions rather than stating things that must happen ;-)

Specifically, on macOS/FreeBSD, it looks like this: https://opensource.apple.com/source/Libc/Libc-1439.40.11/gen/FreeBSD/readdir.c.auto.html

ghost · 2021-02-25T12:15:48Z

Hello @akoeplinger!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (`@msftbot`) and give me an instruction to get started! Learn more here.

akoeplinger · 2021-02-25T17:53:33Z

Test failures are due to #48751.

Therzok · 2021-02-24T09:29:37Z

Fixes#47584

Fixesdotnet#47584

stephentoub

Might be worth adding a comment to the effect that EINTR isn't documented but has been shown to happen in practice. Otherwise, LGTM. Thanks for the fix.

Therzok · 2021-02-24T12:14:48Z

Added comments. I'm pretty sure readdir_r is being used on macOS, so I didn't guard readdir too.

akoeplinger · 2021-02-24T12:34:23Z

+ int error;
+
+ // EINTR isn't documented, happens in practice on macOS.
+ while ((error = readdir_r(dir, entry, &result)) && error == EINTR);


are you sure the EINTR is returned as the return value and not in errno?

I don't have a reliable repro, but I can look in xnu source. I can adapt it so it checks errno.

Seems like readdir_r sets the return value to whatever is in errno?

I've read a few man pages of different OSes and there seems to be little consistency regarding this.
If using errno works on macOS then I'd prefer that since it's what we use everywhere else.

I've changed it.

If using errno works on macOS then I'd prefer that since it's what we use everywhere else.
Except this API explicitly says errors are returned rather than surfacing through errno. Is there an example man page that says readdir_r sets errno? What happens if a readdir_r implementation doesn't touch errno at all, errno retains an EINTR value from prior to the readdir_r call, and readdir_r hits another error... might we end up in an infinite loop?

I can change the code back to checking the return code :D

Before you do, I'd like to hear from @akoeplinger :) I was actually asking questions rather than stating things that must happen ;-)

Specifically, on macOS/FreeBSD, it looks like this: https://opensource.apple.com/source/Libc/Libc-1439.40.11/gen/FreeBSD/readdir.c.auto.html

ghost · 2021-02-25T12:15:48Z

Hello @akoeplinger!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (`@msftbot`) and give me an instruction to get started! Learn more here.

akoeplinger · 2021-02-25T17:53:33Z

Test failures are due to #48751.

Therzok · 2021-02-24T09:29:37Z

Fixes#47584

Fixesdotnet#47584

stephentoub

Might be worth adding a comment to the effect that EINTR isn't documented but has been shown to happen in practice. Otherwise, LGTM. Thanks for the fix.

Therzok · 2021-02-24T12:14:48Z

Added comments. I'm pretty sure readdir_r is being used on macOS, so I didn't guard readdir too.

akoeplinger · 2021-02-24T12:34:23Z

+ int error;
+
+ // EINTR isn't documented, happens in practice on macOS.
+ while ((error = readdir_r(dir, entry, &result)) && error == EINTR);


are you sure the EINTR is returned as the return value and not in errno?

I don't have a reliable repro, but I can look in xnu source. I can adapt it so it checks errno.

Seems like readdir_r sets the return value to whatever is in errno?

I've read a few man pages of different OSes and there seems to be little consistency regarding this.
If using errno works on macOS then I'd prefer that since it's what we use everywhere else.

I've changed it.

If using errno works on macOS then I'd prefer that since it's what we use everywhere else.
Except this API explicitly says errors are returned rather than surfacing through errno. Is there an example man page that says readdir_r sets errno? What happens if a readdir_r implementation doesn't touch errno at all, errno retains an EINTR value from prior to the readdir_r call, and readdir_r hits another error... might we end up in an infinite loop?

I can change the code back to checking the return code :D

Before you do, I'd like to hear from @akoeplinger :) I was actually asking questions rather than stating things that must happen ;-)

Specifically, on macOS/FreeBSD, it looks like this: https://opensource.apple.com/source/Libc/Libc-1439.40.11/gen/FreeBSD/readdir.c.auto.html

ghost · 2021-02-25T12:15:48Z

Hello @akoeplinger!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (`@msftbot`) and give me an instruction to get started! Learn more here.

akoeplinger · 2021-02-25T17:53:33Z

Test failures are due to #48751.

Therzok · 2021-02-24T09:29:37Z

Fixes#47584

Fixesdotnet#47584

stephentoub

Might be worth adding a comment to the effect that EINTR isn't documented but has been shown to happen in practice. Otherwise, LGTM. Thanks for the fix.

Therzok · 2021-02-24T12:14:48Z

Added comments. I'm pretty sure readdir_r is being used on macOS, so I didn't guard readdir too.

akoeplinger · 2021-02-24T12:34:23Z

+ int error;
+
+ // EINTR isn't documented, happens in practice on macOS.
+ while ((error = readdir_r(dir, entry, &result)) && error == EINTR);


are you sure the EINTR is returned as the return value and not in errno?

I don't have a reliable repro, but I can look in xnu source. I can adapt it so it checks errno.

Seems like readdir_r sets the return value to whatever is in errno?

I've read a few man pages of different OSes and there seems to be little consistency regarding this.
If using errno works on macOS then I'd prefer that since it's what we use everywhere else.

I've changed it.

If using errno works on macOS then I'd prefer that since it's what we use everywhere else.
Except this API explicitly says errors are returned rather than surfacing through errno. Is there an example man page that says readdir_r sets errno? What happens if a readdir_r implementation doesn't touch errno at all, errno retains an EINTR value from prior to the readdir_r call, and readdir_r hits another error... might we end up in an infinite loop?

I can change the code back to checking the return code :D

Before you do, I'd like to hear from @akoeplinger :) I was actually asking questions rather than stating things that must happen ;-)

Specifically, on macOS/FreeBSD, it looks like this: https://opensource.apple.com/source/Libc/Libc-1439.40.11/gen/FreeBSD/readdir.c.auto.html

ghost · 2021-02-25T12:15:48Z

Hello @akoeplinger!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (`@msftbot`) and give me an instruction to get started! Learn more here.

akoeplinger · 2021-02-25T17:53:33Z

Test failures are due to #48751.

Therzok · 2021-02-24T09:29:37Z

Fixes#47584

Fixesdotnet#47584

stephentoub

Might be worth adding a comment to the effect that EINTR isn't documented but has been shown to happen in practice. Otherwise, LGTM. Thanks for the fix.

Therzok · 2021-02-24T12:14:48Z

Added comments. I'm pretty sure readdir_r is being used on macOS, so I didn't guard readdir too.

akoeplinger · 2021-02-24T12:34:23Z

+ int error;
+
+ // EINTR isn't documented, happens in practice on macOS.
+ while ((error = readdir_r(dir, entry, &result)) && error == EINTR);


are you sure the EINTR is returned as the return value and not in errno?

I don't have a reliable repro, but I can look in xnu source. I can adapt it so it checks errno.

Seems like readdir_r sets the return value to whatever is in errno?

I've read a few man pages of different OSes and there seems to be little consistency regarding this.
If using errno works on macOS then I'd prefer that since it's what we use everywhere else.

I've changed it.

If using errno works on macOS then I'd prefer that since it's what we use everywhere else.
Except this API explicitly says errors are returned rather than surfacing through errno. Is there an example man page that says readdir_r sets errno? What happens if a readdir_r implementation doesn't touch errno at all, errno retains an EINTR value from prior to the readdir_r call, and readdir_r hits another error... might we end up in an infinite loop?

I can change the code back to checking the return code :D

Before you do, I'd like to hear from @akoeplinger :) I was actually asking questions rather than stating things that must happen ;-)

Specifically, on macOS/FreeBSD, it looks like this: https://opensource.apple.com/source/Libc/Libc-1439.40.11/gen/FreeBSD/readdir.c.auto.html

ghost · 2021-02-25T12:15:48Z

Hello @akoeplinger!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (`@msftbot`) and give me an instruction to get started! Learn more here.

akoeplinger · 2021-02-25T17:53:33Z

Test failures are due to #48751.

Therzok · 2021-02-24T09:29:37Z

Fixes#47584

Fixesdotnet#47584

stephentoub

Might be worth adding a comment to the effect that EINTR isn't documented but has been shown to happen in practice. Otherwise, LGTM. Thanks for the fix.

Therzok · 2021-02-24T12:14:48Z

Added comments. I'm pretty sure readdir_r is being used on macOS, so I didn't guard readdir too.

akoeplinger · 2021-02-24T12:34:23Z

+ int error;
+
+ // EINTR isn't documented, happens in practice on macOS.
+ while ((error = readdir_r(dir, entry, &result)) && error == EINTR);


are you sure the EINTR is returned as the return value and not in errno?

I don't have a reliable repro, but I can look in xnu source. I can adapt it so it checks errno.

Seems like readdir_r sets the return value to whatever is in errno?

I've read a few man pages of different OSes and there seems to be little consistency regarding this.
If using errno works on macOS then I'd prefer that since it's what we use everywhere else.

I've changed it.

If using errno works on macOS then I'd prefer that since it's what we use everywhere else.
Except this API explicitly says errors are returned rather than surfacing through errno. Is there an example man page that says readdir_r sets errno? What happens if a readdir_r implementation doesn't touch errno at all, errno retains an EINTR value from prior to the readdir_r call, and readdir_r hits another error... might we end up in an infinite loop?

I can change the code back to checking the return code :D

Before you do, I'd like to hear from @akoeplinger :) I was actually asking questions rather than stating things that must happen ;-)

Specifically, on macOS/FreeBSD, it looks like this: https://opensource.apple.com/source/Libc/Libc-1439.40.11/gen/FreeBSD/readdir.c.auto.html

ghost · 2021-02-25T12:15:48Z

Hello @akoeplinger!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (`@msftbot`) and give me an instruction to get started! Learn more here.

akoeplinger · 2021-02-25T17:53:33Z

Test failures are due to #48751.

Therzok · 2021-02-24T09:29:37Z

Fixes#47584

Fixesdotnet#47584

stephentoub

Might be worth adding a comment to the effect that EINTR isn't documented but has been shown to happen in practice. Otherwise, LGTM. Thanks for the fix.

Therzok · 2021-02-24T12:14:48Z

Added comments. I'm pretty sure readdir_r is being used on macOS, so I didn't guard readdir too.

akoeplinger · 2021-02-24T12:34:23Z

+ int error;
+
+ // EINTR isn't documented, happens in practice on macOS.
+ while ((error = readdir_r(dir, entry, &result)) && error == EINTR);


are you sure the EINTR is returned as the return value and not in errno?

I don't have a reliable repro, but I can look in xnu source. I can adapt it so it checks errno.

Seems like readdir_r sets the return value to whatever is in errno?

I've read a few man pages of different OSes and there seems to be little consistency regarding this.
If using errno works on macOS then I'd prefer that since it's what we use everywhere else.

I've changed it.

If using errno works on macOS then I'd prefer that since it's what we use everywhere else.
Except this API explicitly says errors are returned rather than surfacing through errno. Is there an example man page that says readdir_r sets errno? What happens if a readdir_r implementation doesn't touch errno at all, errno retains an EINTR value from prior to the readdir_r call, and readdir_r hits another error... might we end up in an infinite loop?

I can change the code back to checking the return code :D

Before you do, I'd like to hear from @akoeplinger :) I was actually asking questions rather than stating things that must happen ;-)

Specifically, on macOS/FreeBSD, it looks like this: https://opensource.apple.com/source/Libc/Libc-1439.40.11/gen/FreeBSD/readdir.c.auto.html

ghost · 2021-02-25T12:15:48Z

Hello @akoeplinger!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (`@msftbot`) and give me an instruction to get started! Learn more here.

akoeplinger · 2021-02-25T17:53:33Z

Test failures are due to #48751.

Fix macOS dir behaviour by providing EINTR handling
8fd2777
Fixesdotnet#47584

ghost added the area-PAL-libraries label Feb 24, 2021

marek-safar requested a review from janvorli February 24, 2021 09:31

stephentoub approved these changes Feb 24, 2021
View reviewed changes

Add comments
89605a0

stephentoub approved these changes Feb 24, 2021
View reviewed changes

akoeplinger reviewed Feb 24, 2021
View reviewed changes

Use errno instead of error for looping.
82fa411

akoeplinger approved these changes Feb 25, 2021
View reviewed changes

akoeplinger added the auto-merge label Feb 25, 2021

akoeplinger merged commit 5a561eb into dotnet:masterFeb 25, 2021

Therzok deleted the macos-eintr branch February 25, 2021 20:19

ghost locked as resolved and limited conversation to collaborators Mar 28, 2021

jeffhandley added area-System.Runtime.InteropServices and removed area-PAL-libraries labels Nov 11, 2021

Fix macOS dir behaviour by providing EINTR handling
8fd2777
Fixesdotnet#47584

ghost added the area-PAL-libraries label Feb 24, 2021

marek-safar requested a review from janvorli February 24, 2021 09:31

stephentoub approved these changes Feb 24, 2021
View reviewed changes

Add comments
89605a0

stephentoub approved these changes Feb 24, 2021
View reviewed changes

akoeplinger reviewed Feb 24, 2021
View reviewed changes

Use errno instead of error for looping.
82fa411

akoeplinger approved these changes Feb 25, 2021
View reviewed changes

akoeplinger added the auto-merge label Feb 25, 2021

akoeplinger merged commit 5a561eb into dotnet:masterFeb 25, 2021

Therzok deleted the macos-eintr branch February 25, 2021 20:19

ghost locked as resolved and limited conversation to collaborators Mar 28, 2021

jeffhandley added area-System.Runtime.InteropServices and removed area-PAL-libraries labels Nov 11, 2021

Fix macOS dir behaviour by providing EINTR handling
8fd2777
Fixesdotnet#47584

ghost added the area-PAL-libraries label Feb 24, 2021

marek-safar requested a review from janvorli February 24, 2021 09:31

stephentoub approved these changes Feb 24, 2021
View reviewed changes

Add comments
89605a0

stephentoub approved these changes Feb 24, 2021
View reviewed changes

akoeplinger reviewed Feb 24, 2021
View reviewed changes

Use errno instead of error for looping.
82fa411

akoeplinger approved these changes Feb 25, 2021
View reviewed changes

akoeplinger added the auto-merge label Feb 25, 2021

akoeplinger merged commit 5a561eb into dotnet:masterFeb 25, 2021

Therzok deleted the macos-eintr branch February 25, 2021 20:19

ghost locked as resolved and limited conversation to collaborators Mar 28, 2021

jeffhandley added area-System.Runtime.InteropServices and removed area-PAL-libraries labels Nov 11, 2021

Fix macOS dir behaviour by providing EINTR handling
8fd2777
Fixesdotnet#47584

ghost added the area-PAL-libraries label Feb 24, 2021

marek-safar requested a review from janvorli February 24, 2021 09:31

stephentoub approved these changes Feb 24, 2021
View reviewed changes

Add comments
89605a0

stephentoub approved these changes Feb 24, 2021
View reviewed changes

akoeplinger reviewed Feb 24, 2021
View reviewed changes

Use errno instead of error for looping.
82fa411

akoeplinger approved these changes Feb 25, 2021
View reviewed changes

akoeplinger added the auto-merge label Feb 25, 2021

akoeplinger merged commit 5a561eb into dotnet:masterFeb 25, 2021

Therzok deleted the macos-eintr branch February 25, 2021 20:19

ghost locked as resolved and limited conversation to collaborators Mar 28, 2021

jeffhandley added area-System.Runtime.InteropServices and removed area-PAL-libraries labels Nov 11, 2021

Fix macOS dir behaviour by providing EINTR handling
8fd2777
Fixesdotnet#47584

ghost added the area-PAL-libraries label Feb 24, 2021

marek-safar requested a review from janvorli February 24, 2021 09:31

stephentoub approved these changes Feb 24, 2021
View reviewed changes

Add comments
89605a0

stephentoub approved these changes Feb 24, 2021
View reviewed changes

akoeplinger reviewed Feb 24, 2021
View reviewed changes

Use errno instead of error for looping.
82fa411

akoeplinger approved these changes Feb 25, 2021
View reviewed changes

akoeplinger added the auto-merge label Feb 25, 2021

akoeplinger merged commit 5a561eb into dotnet:masterFeb 25, 2021

Therzok deleted the macos-eintr branch February 25, 2021 20:19

ghost locked as resolved and limited conversation to collaborators Mar 28, 2021

jeffhandley added area-System.Runtime.InteropServices and removed area-PAL-libraries labels Nov 11, 2021

Fix macOS dir behaviour by providing EINTR handling
8fd2777
Fixesdotnet#47584

ghost added the area-PAL-libraries label Feb 24, 2021

marek-safar requested a review from janvorli February 24, 2021 09:31

stephentoub approved these changes Feb 24, 2021
View reviewed changes

Add comments
89605a0

stephentoub approved these changes Feb 24, 2021
View reviewed changes

akoeplinger reviewed Feb 24, 2021
View reviewed changes

Use errno instead of error for looping.
82fa411

akoeplinger approved these changes Feb 25, 2021
View reviewed changes

akoeplinger added the auto-merge label Feb 25, 2021

akoeplinger merged commit 5a561eb into dotnet:masterFeb 25, 2021

Therzok deleted the macos-eintr branch February 25, 2021 20:19

ghost locked as resolved and limited conversation to collaborators Mar 28, 2021

jeffhandley added area-System.Runtime.InteropServices and removed area-PAL-libraries labels Nov 11, 2021

Fix macOS dir behaviour by providing EINTR handling
8fd2777
Fixesdotnet#47584

ghost added the area-PAL-libraries label Feb 24, 2021

marek-safar requested a review from janvorli February 24, 2021 09:31

stephentoub approved these changes Feb 24, 2021
View reviewed changes

Add comments
89605a0

stephentoub approved these changes Feb 24, 2021
View reviewed changes

akoeplinger reviewed Feb 24, 2021
View reviewed changes

Use errno instead of error for looping.
82fa411

akoeplinger approved these changes Feb 25, 2021
View reviewed changes

akoeplinger added the auto-merge label Feb 25, 2021

akoeplinger merged commit 5a561eb into dotnet:masterFeb 25, 2021

Therzok deleted the macos-eintr branch February 25, 2021 20:19

ghost locked as resolved and limited conversation to collaborators Mar 28, 2021

jeffhandley added area-System.Runtime.InteropServices and removed area-PAL-libraries labels Nov 11, 2021

Fix macOS dir behaviour by providing EINTR handling
8fd2777
Fixesdotnet#47584

ghost added the area-PAL-libraries label Feb 24, 2021

marek-safar requested a review from janvorli February 24, 2021 09:31

stephentoub approved these changes Feb 24, 2021
View reviewed changes

Add comments
89605a0

stephentoub approved these changes Feb 24, 2021
View reviewed changes

akoeplinger reviewed Feb 24, 2021
View reviewed changes

Use errno instead of error for looping.
82fa411

akoeplinger approved these changes Feb 25, 2021
View reviewed changes

akoeplinger added the auto-merge label Feb 25, 2021

akoeplinger merged commit 5a561eb into dotnet:masterFeb 25, 2021

Therzok deleted the macos-eintr branch February 25, 2021 20:19

ghost locked as resolved and limited conversation to collaborators Mar 28, 2021

jeffhandley added area-System.Runtime.InteropServices and removed area-PAL-libraries labels Nov 11, 2021

Uh oh!

Conversation

Therzok commented Feb 24, 2021

Uh oh!

stephentoub left a comment

Choose a reason for hiding this comment

Uh oh!

Therzok commented Feb 24, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TherzokFeb 25, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ghost commented Feb 25, 2021

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

Uh oh!

akoeplinger commented Feb 25, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

Therzok commented Feb 24, 2021

Uh oh!

stephentoub left a comment

Choose a reason for hiding this comment

Uh oh!

Therzok commented Feb 24, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TherzokFeb 25, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ghost commented Feb 25, 2021

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

Uh oh!

akoeplinger commented Feb 25, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

TherzokFeb 25, 2021•
edited
Loading

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (`@msftbot`) and give me an instruction to get started! Learn more here.

TherzokFeb 25, 2021•
edited
Loading

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (`@msftbot`) and give me an instruction to get started! Learn more here.

TherzokFeb 25, 2021•
edited
Loading