Why does the cost centre stack gets jumbled up in the Haskell profile file?

I am trying to profile my project in Haskell, but in the profile file (.prof) I am seeing the order in which the function stack is getting printed seems a little jumbled up.

For example, when checking the cost center (https://hackage.haskell.org/package/ghc-prof-1.4.1.12/docs/src/GHC.Prof.Types.html#CostCentre) stack in the .prof file, below is the cost center stack I see.

logError
  log
   findCustomerFromDB
    getDBConfig
     rSet
      rSetB
       preInitEncryptedOrder
        decodeOrderDetails
         mkOptionKey
          encode
           fromEncoding
           genericToJSON
            unTagged
           value
            encodeToBuilder
             array
              unId
              emptyArray_

But, I am not able to wrap my head around why inside the log function, profiler is printing database calls as its children.
(PS: In code, I’m not doing DB call inside log function)

The call center stack is constructed exactly, as cost centers are entered and exited, so its construction is not affected by sampling. Not all call center stacks that exist during the execution of a program will be sampled, but any call center stack that is sampled will be an actual call stack, not some artifact of sampling error.

In addition, call center stacks are stored in thunks at the time of creation and restored when the thunk is evaluated, so lazy evaluation will not produce weird, hybrid stacks representing function calls that happened to be in effect when a lazy value was actually forced at some unpredictable time.

So, provided these cost centers have been correctly named (i.e., no stray SCC pragmas with the wrong name floating around) and provided you aren't looking at the code for one function named log and comparing it to the profiling information for a totally different log function, there is no logical explanation for your call stack other than the obvious one: findCustomerFromDB is, in fact, called by the log function, either directly, or through some other inlined function.

I'd suggest scrutinizing your log function and checking if it calls a helper function that adds some debugging information to logged strings, like the name of the customer that initiated the offending request.