ASP.NET Core can't step into endpoint method?












-1















I have an API controller with a method like so:



    [HttpGet]
[Route("~/api/groups/{groupId}/feeds/{feedItemId}/flag")]
[FeedItemAccess(AccessLevelTypes.GroupMember, "groupId")]
public async Task<IActionResult> FlagFeedItem([FromRoute] int groupId, [FromRoute] long feedItemId)
{
try
{
await _feedManagementService.FlagMessage(groupId, feedItemId);
return Ok();
}
catch (Exception ex)
{
_logger.LogError(ex, "FlagFeedItem(int)");
return new OopsResult(ex);
}
}


I put breakpoints on the await line and on the _logger line. I then use my REST client to hit the specified endpoint (http://myhost/api/groups/1/feeds/1/flag) in debug mode.



I immediately get back a blank 200 response... but the await method is never hit, nor is the service underneath, and I never reach the breakpoint(s). I'm scratching my head on this. I would think this was a thread deadlocking issue but for the fact that it actually returns a 200 status code.



What could be the problem here? The routing appears to be correct, I can intercept on the controller's constructor, all looks fine... but when it gets here, the system just decides it doesn't actually need to do anything.



BTW, the FeedItemAccess filter just checks the user's tenancy rights to connect to the endpoint; it also appears to be working fine (I can intercept on that too and it's leaving the filter under success conditions).










share|improve this question























  • Have you tried the old "restart Visual Studio" and "clean solution"?

    – DavidG
    Nov 14 '18 at 0:00











  • yeah... though I'm about to try "restart the computer and/ or drop it in the ocean" next... it's just this one endpoint. Makes no sense.

    – Jeremy Holovacs
    Nov 14 '18 at 0:05











  • If you change the route attribute but use the same URL, does it still give you HTTP 200?

    – DavidG
    Nov 14 '18 at 0:05











  • What happens if you comment out [FeedItemAccess(AccessLevelTypes.GroupMember, "groupId")]?

    – mjwills
    Nov 14 '18 at 0:06






  • 2





    Well, clearly it is something to do with that attribute.

    – mjwills
    Nov 14 '18 at 0:13
















-1















I have an API controller with a method like so:



    [HttpGet]
[Route("~/api/groups/{groupId}/feeds/{feedItemId}/flag")]
[FeedItemAccess(AccessLevelTypes.GroupMember, "groupId")]
public async Task<IActionResult> FlagFeedItem([FromRoute] int groupId, [FromRoute] long feedItemId)
{
try
{
await _feedManagementService.FlagMessage(groupId, feedItemId);
return Ok();
}
catch (Exception ex)
{
_logger.LogError(ex, "FlagFeedItem(int)");
return new OopsResult(ex);
}
}


I put breakpoints on the await line and on the _logger line. I then use my REST client to hit the specified endpoint (http://myhost/api/groups/1/feeds/1/flag) in debug mode.



I immediately get back a blank 200 response... but the await method is never hit, nor is the service underneath, and I never reach the breakpoint(s). I'm scratching my head on this. I would think this was a thread deadlocking issue but for the fact that it actually returns a 200 status code.



What could be the problem here? The routing appears to be correct, I can intercept on the controller's constructor, all looks fine... but when it gets here, the system just decides it doesn't actually need to do anything.



BTW, the FeedItemAccess filter just checks the user's tenancy rights to connect to the endpoint; it also appears to be working fine (I can intercept on that too and it's leaving the filter under success conditions).










share|improve this question























  • Have you tried the old "restart Visual Studio" and "clean solution"?

    – DavidG
    Nov 14 '18 at 0:00











  • yeah... though I'm about to try "restart the computer and/ or drop it in the ocean" next... it's just this one endpoint. Makes no sense.

    – Jeremy Holovacs
    Nov 14 '18 at 0:05











  • If you change the route attribute but use the same URL, does it still give you HTTP 200?

    – DavidG
    Nov 14 '18 at 0:05











  • What happens if you comment out [FeedItemAccess(AccessLevelTypes.GroupMember, "groupId")]?

    – mjwills
    Nov 14 '18 at 0:06






  • 2





    Well, clearly it is something to do with that attribute.

    – mjwills
    Nov 14 '18 at 0:13














-1












-1








-1








I have an API controller with a method like so:



    [HttpGet]
[Route("~/api/groups/{groupId}/feeds/{feedItemId}/flag")]
[FeedItemAccess(AccessLevelTypes.GroupMember, "groupId")]
public async Task<IActionResult> FlagFeedItem([FromRoute] int groupId, [FromRoute] long feedItemId)
{
try
{
await _feedManagementService.FlagMessage(groupId, feedItemId);
return Ok();
}
catch (Exception ex)
{
_logger.LogError(ex, "FlagFeedItem(int)");
return new OopsResult(ex);
}
}


I put breakpoints on the await line and on the _logger line. I then use my REST client to hit the specified endpoint (http://myhost/api/groups/1/feeds/1/flag) in debug mode.



I immediately get back a blank 200 response... but the await method is never hit, nor is the service underneath, and I never reach the breakpoint(s). I'm scratching my head on this. I would think this was a thread deadlocking issue but for the fact that it actually returns a 200 status code.



What could be the problem here? The routing appears to be correct, I can intercept on the controller's constructor, all looks fine... but when it gets here, the system just decides it doesn't actually need to do anything.



BTW, the FeedItemAccess filter just checks the user's tenancy rights to connect to the endpoint; it also appears to be working fine (I can intercept on that too and it's leaving the filter under success conditions).










share|improve this question














I have an API controller with a method like so:



    [HttpGet]
[Route("~/api/groups/{groupId}/feeds/{feedItemId}/flag")]
[FeedItemAccess(AccessLevelTypes.GroupMember, "groupId")]
public async Task<IActionResult> FlagFeedItem([FromRoute] int groupId, [FromRoute] long feedItemId)
{
try
{
await _feedManagementService.FlagMessage(groupId, feedItemId);
return Ok();
}
catch (Exception ex)
{
_logger.LogError(ex, "FlagFeedItem(int)");
return new OopsResult(ex);
}
}


I put breakpoints on the await line and on the _logger line. I then use my REST client to hit the specified endpoint (http://myhost/api/groups/1/feeds/1/flag) in debug mode.



I immediately get back a blank 200 response... but the await method is never hit, nor is the service underneath, and I never reach the breakpoint(s). I'm scratching my head on this. I would think this was a thread deadlocking issue but for the fact that it actually returns a 200 status code.



What could be the problem here? The routing appears to be correct, I can intercept on the controller's constructor, all looks fine... but when it gets here, the system just decides it doesn't actually need to do anything.



BTW, the FeedItemAccess filter just checks the user's tenancy rights to connect to the endpoint; it also appears to be working fine (I can intercept on that too and it's leaving the filter under success conditions).







c# asp.net-core asp.net-core-webapi






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 13 '18 at 23:54









Jeremy HolovacsJeremy Holovacs

12k2175184




12k2175184













  • Have you tried the old "restart Visual Studio" and "clean solution"?

    – DavidG
    Nov 14 '18 at 0:00











  • yeah... though I'm about to try "restart the computer and/ or drop it in the ocean" next... it's just this one endpoint. Makes no sense.

    – Jeremy Holovacs
    Nov 14 '18 at 0:05











  • If you change the route attribute but use the same URL, does it still give you HTTP 200?

    – DavidG
    Nov 14 '18 at 0:05











  • What happens if you comment out [FeedItemAccess(AccessLevelTypes.GroupMember, "groupId")]?

    – mjwills
    Nov 14 '18 at 0:06






  • 2





    Well, clearly it is something to do with that attribute.

    – mjwills
    Nov 14 '18 at 0:13



















  • Have you tried the old "restart Visual Studio" and "clean solution"?

    – DavidG
    Nov 14 '18 at 0:00











  • yeah... though I'm about to try "restart the computer and/ or drop it in the ocean" next... it's just this one endpoint. Makes no sense.

    – Jeremy Holovacs
    Nov 14 '18 at 0:05











  • If you change the route attribute but use the same URL, does it still give you HTTP 200?

    – DavidG
    Nov 14 '18 at 0:05











  • What happens if you comment out [FeedItemAccess(AccessLevelTypes.GroupMember, "groupId")]?

    – mjwills
    Nov 14 '18 at 0:06






  • 2





    Well, clearly it is something to do with that attribute.

    – mjwills
    Nov 14 '18 at 0:13

















Have you tried the old "restart Visual Studio" and "clean solution"?

– DavidG
Nov 14 '18 at 0:00





Have you tried the old "restart Visual Studio" and "clean solution"?

– DavidG
Nov 14 '18 at 0:00













yeah... though I'm about to try "restart the computer and/ or drop it in the ocean" next... it's just this one endpoint. Makes no sense.

– Jeremy Holovacs
Nov 14 '18 at 0:05





yeah... though I'm about to try "restart the computer and/ or drop it in the ocean" next... it's just this one endpoint. Makes no sense.

– Jeremy Holovacs
Nov 14 '18 at 0:05













If you change the route attribute but use the same URL, does it still give you HTTP 200?

– DavidG
Nov 14 '18 at 0:05





If you change the route attribute but use the same URL, does it still give you HTTP 200?

– DavidG
Nov 14 '18 at 0:05













What happens if you comment out [FeedItemAccess(AccessLevelTypes.GroupMember, "groupId")]?

– mjwills
Nov 14 '18 at 0:06





What happens if you comment out [FeedItemAccess(AccessLevelTypes.GroupMember, "groupId")]?

– mjwills
Nov 14 '18 at 0:06




2




2





Well, clearly it is something to do with that attribute.

– mjwills
Nov 14 '18 at 0:13





Well, clearly it is something to do with that attribute.

– mjwills
Nov 14 '18 at 0:13












1 Answer
1






active

oldest

votes


















0














As @mjwills suggested, I should have been a bit more careful in dismissing what could or could not cause this behavior. I had thought I understood how the action filter was supposed to behave, and since it seemed to be doing what I wanted, I knew it wasn't the problem... but it actually was.



Removing all possible culprits and methodically adding them back in... sometimes it's the only way to find the problem.






share|improve this answer























    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53291185%2fasp-net-core-cant-step-into-endpoint-method%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0














    As @mjwills suggested, I should have been a bit more careful in dismissing what could or could not cause this behavior. I had thought I understood how the action filter was supposed to behave, and since it seemed to be doing what I wanted, I knew it wasn't the problem... but it actually was.



    Removing all possible culprits and methodically adding them back in... sometimes it's the only way to find the problem.






    share|improve this answer




























      0














      As @mjwills suggested, I should have been a bit more careful in dismissing what could or could not cause this behavior. I had thought I understood how the action filter was supposed to behave, and since it seemed to be doing what I wanted, I knew it wasn't the problem... but it actually was.



      Removing all possible culprits and methodically adding them back in... sometimes it's the only way to find the problem.






      share|improve this answer


























        0












        0








        0







        As @mjwills suggested, I should have been a bit more careful in dismissing what could or could not cause this behavior. I had thought I understood how the action filter was supposed to behave, and since it seemed to be doing what I wanted, I knew it wasn't the problem... but it actually was.



        Removing all possible culprits and methodically adding them back in... sometimes it's the only way to find the problem.






        share|improve this answer













        As @mjwills suggested, I should have been a bit more careful in dismissing what could or could not cause this behavior. I had thought I understood how the action filter was supposed to behave, and since it seemed to be doing what I wanted, I knew it wasn't the problem... but it actually was.



        Removing all possible culprits and methodically adding them back in... sometimes it's the only way to find the problem.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 17 '18 at 0:37









        Jeremy HolovacsJeremy Holovacs

        12k2175184




        12k2175184






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53291185%2fasp-net-core-cant-step-into-endpoint-method%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Florida Star v. B. J. F.

            Danny Elfman

            Lugert, Oklahoma