blkangel,

Где описание механизма, как у вас фетчится карточка, откуда берется имя пользователя, и как с ними связана P303_TABLE_ID ?
Хрустального шара у меня нету.

Конечно, куки и браузерный кеш не причем (если не мудрили с ними специально).
Там всё что угодно может быть:

- Запрос возвращает несколько строк, берется первая

- Вьюшки с контекстами, которые неправильно инициализируются, без знания архитектуры апекса

- написана своя Sentry Function, с ошибкой

- Состояние сессии старое остается (а хранится оно в таблицах oracle!), если в этом дело, тогда самое простое - очищать состояние сессии, указав номер страницы в 6-м параметре url указанной выше ссылки

- Ошибка в коде (в 15-й строке)

blkangelпочему после очистки помогает?

Потому что после очистки кукисов браузер текущую сессию забывает, тем самым устанавливает новую сессию

blkangelSvDev- написана своя Sentry Function, с ошибкой

Не знаю про что Вы.

Функция, которая в том числе занимается сопоставлением кукисов и существующей сессией в url

blkangelSvDev,

Фетчится автоматическим процессом по первичному уникальному ключу P303_TABLE_ID.

Если карточка вычисляется из обычной таблицы стандартным апексным фетчем, и тип source у items, исключительно DATABASE COLUMN, тогда пока вижу только вариант с сохранением старой сессии, и это должно легко воспроизодиться.

А вот если у вас что-то более сложное, тогда запросто при ошибках в коде можно получить такой непостоянный эффект.
Например, если старое значение остаётся в одном items со сложной логикой вычисления, потом используется при фетче - легко лечится очисткой состояния сессии.

или, если приоритет выполнения процессов одинаковый или неопределен, процессы могут срабатывать в разном порядке, ломая задуманную вами логику.

в любом случае в пакете apex_debug есть всё необходимое, чтобы собрать отладочную информацию, даже если вы не можете воспроизвести ошибку.

blkangel,

apex_xxxxx.wwv_flow_data (только не вздумайте в коде приложения использовать)

blkangelПеред автоматическим фетчем есть присвоение P303_TABLE_ID из переменной приложения. Кстати может в ней вина.
Переменная приложения - item ?
Тогда непонятно, зачем вы её в url передаете,
то что устанавливается через url, устанавливается на очень ранней стадии, соответственно получается у вас переприсваивается.

blkangel,

Видимо, значит, всё дело в этом промежуточным звене.
Как и где устанавливается имеет значение.

Добавлю, редко, но приходилось сталкиваться с ситуациями неопределенности приоритета.
Т.е. когда непонятно какие вычисления должны происходить до, какие после.
В этом случае порядок может быть как повезет, то один, то другой (не обязательно с одинаковой частотой).

В последний раз, например, у меня была ситуация, когда Application Computation, хотя он был один, выполнялся то до, то после каких-то процессов висящих на той же точке выполнения.

Если непонятно где ошибка, значит нужно собрать отладочную информацию через apex_debug.