$routeParams are lost after $http call (Angular bug)

[DinisCruz]

Here is a weird bug (which looks like an issue inside Angular)

When working on the Team-Data api (re #206) I started to have a weird behaviour in one of the tests

(see how the value of $routeParams is lost and how line 17 on Team-Data.coffee is never hit)

Here is the console.log mess that allowed me to debug it

To confirm that the prob was not in my code and it was in Angular I wrote these two tests

  fit 'Angular bug $routeParams is lost after API call', ->
    inject ($routeParams)=>
      $routeParams.project = 'bsimm'
      $routeParams.assert_Is project: 'bsimm'           # $routeParams is set
      call_API 'project_Schema', ['bsimm'], (data)=>    # make request using test API
        data.config.schema.assert_Is 'bsimm'            # confirm we got data ok
        $routeParams.assert_Is {}                       # bug: $routeParams data is lost

  fit 'Angular bug $routeParams is lost after $http.get call', ->
    inject ($routeParams, $http, $httpBackend)=>
      $routeParams.project = 'bsimm'
      $routeParams.assert_Is project: 'bsimm'           # $routeParams is set
      url = '/api/v1/project/schema/bsimm'
      $http.get url                                     # make request using angular's $http object
        .then (response)->
          response.data.config.schema.assert_Is 'bsimm' # confirm we got data  ok
          $routeParams.assert_Is {}                     # bug: $routeParams data is lost

      $httpBackend.flush()

note how on the 2nd test I'm using the native $http Angular method where the $routeParams is ok before the call and not ok after the call

this means that something is going on inside that call (note that at the moment I don't think this will after the current code, due to the way data is retrieved from $routeParams, but that could very easily happen in the future)

[DinisCruz]

debugging this inside the Angular framework

At this stage the values are still ok

At the end of the function $http(requestConfig) method it is still ok

before the call to $http.flush(); all is still good (i.e. $routeParams value is still ok)

(note the different ways that I'm finding to get the value from the $injector api)

Inside the $digest() method, there was the call to the serverRequest method (that was scheduled in the first screenshot)

before call to sendReq(config, reqData) all is still good

before call to function $httpBackend(method, url, data, callback, headers... all still good

.... to be continued after lunch ...

[DinisCruz]

All good at function transformResponse(response)

after this I gave up tracing it since IntelliJ was taking too long between frames (I think on loading the data)

from https://docs.angularjs.org/api/ngRoute/service/$routeParams one possible problem could be a route change, although at the moment I'm not seeing how that could be occuring

[DinisCruz]

For reference here is the lack of code coverage that cause this rabbit hole to be followed

[DinisCruz]

here is the test that includes the small work around

  it 'load_Data (from cache)', ->
    inject ($routeParams)=>
      $routeParams.project = 'bsimm'
      $routeParams.team    = 'team-A'
      using team_Data, ->
        @.load_Data ()=>
          $routeParams.project = 'bsimm'                        # see https://github.com/OWASP/Maturity-Models/issues/212   
          $routeParams.team    = 'team-A'                       # for reason this need to be set here again
          @.load_Data ()=>
            @.data.keys(  ).assert_Is [ 'metadata', 'activities' ]
            @.load_Data ()=>
        $httpBackend$.flush()

that confirms the code execution

[DinisCruz]

closing this as 'could not find root cause'