Currently, the profile service keeps track of state via an internal store. The store is mistakenly referred to as a cache and while there's definitely a write-through mechanism in place, there's no corresponding read from tc when the cache goes stale. Indeed, the "cache" is never considered stale!
It should be fairly easy to parse out the profiles assigned to devices from the output of tc filter show dev <interface>, given that the flow IDs of those profiles are known ahead of time and are mapped easily (see getFlowID in src/server/profiles.js).
Currently, the profile service keeps track of state via an internal store. The store is mistakenly referred to as a cache and while there's definitely a write-through mechanism in place, there's no corresponding read from
tcwhen the cache goes stale. Indeed, the "cache" is never considered stale!It should be fairly easy to parse out the profiles assigned to devices from the output of
tc filter show dev <interface>, given that the flow IDs of those profiles are known ahead of time and are mapped easily (seegetFlowIDinsrc/server/profiles.js).