# Виправлення PR оновлення refcache

> Як вирішити проблему з невирішеними записами, що не належать до кодів 2XX, у PR щодо оновлення кешу посилань otelbot.

---

LLMS index: [llms.txt](/llms.txt)

---

Виконайте ці кроки, щоб вирішити проблему з невирішеними записами, що не належать до кодів 2XX, у `static/refcache.json` у PR `otelbot/refcache-refresh`. Цей процес може включати оновлення або видалення недійсних посилань на сайті, а потім повторне оновлення кешу посилань, поки не залишиться жодного запису, що не належить до кодів 2XX.

## Підготовка {#preparation}

Ці кроки передбачають, що у вас є локальна копія репозиторію з налаштованим віддаленим репозиторієм `upstream`, який вказує на основний репозиторій. Виконуйте ці кроки локально з кореня репозиторію.

1. Визначте PR, повʼязаний з upstream `otelbot/refcache-refresh`.
2. Якщо жодного не існує, зупиніться.
3. Якщо локальна гілка `otelbot/refcache-refresh` вже існує і містить коміти, яких немає в `upstream/otelbot/refcache-refresh`, зробіть їх резервну копію або зупиніться перед скиданням будь-яких змін.
4. Перейдіть на гілку PR за допомогою `gh pr checkout <num>`. Якщо це не вдається через те, що локальна гілка розійшлася і ви вже зробили резервну копію будь-яких локальних комітів, вирівняйте її з upstream:

   ```sh
   git fetch upstream
   git checkout otelbot/refcache-refresh
   git reset --hard upstream/otelbot/refcache-refresh
   ```

5. Якщо будь-які модулі контенту застаріли, запустіть `npm run get:submodule`.

## Обробка відповідей 5XX {#handling-5xx-responses}

Статус 5XX зазвичай є тимчасовим. Якщо `static/refcache.json` або `./scripts/double-check-refcache-4XX.mjs` (нижче) повідомляє про статус 5XX для URL, вважайте його ймовірно тимчасовим (сервер недоступний, помилки шлюзу, перевантаження). **Не змінюйте** вміст сайту або посилання лише для обходу 5XX; краще повторно запустити скрипт подвійної перевірки (з `--retry-404`, якщо це корисно) або `npm run fix:refcache` пізніше. Досліджуйте 5XX як реальний дефект лише якщо він **продовжує** виникати протягом кількох запусків і ви підтвердили, що URL в іншому випадку не працює.

## Розвʼязання записів, що не належать до кодів 2XX {#resolve-non-2xx-entries}

1. Запустіть `./scripts/double-check-refcache-4XX.mjs --retry-404`, щоб повторно отримати URL-адреси, які все ще кешуються як 4XX, та фрагментовані URL-адреси, позначені як INVALID FRAGMENT, а потім оновіть `static/refcache.json`. Див. примітку про LinkedIn нижче.
2. Перевірте `static/refcache.json` на наявність залишкових статусів, що не належать до кодів 2XX.
3. Якщо жодного не залишилося, тобто скрипт подвійної перевірки успішний:
   - Поділіться підсумком подвійної перевірки: у вашій відповіді або коментарі до PR (повторно отримані URL-адреси, оновлені записи, остаточні підрахунки HTTP-статусів та “Оброблено N URL-адрес”, коли показано).
   - Якщо `static/refcache.json` змінився, зафіксуйте зміни та надішліть їх до `upstream/otelbot/refcache-refresh` (на цьому етапі).
   - Позначте PR як готовий до перегляду: `gh pr ready <num>`.
   - Увімкніть автоматичне злиття, щоб PR був об'єднаний після отримання всіх схвалень і проходження перевірок: `gh pr merge <num> --auto`.
   - **Нагадайте підтримувачу схвалити** PR, щоб автоматичне злиття могло завершитися. Надішліть посилання на PR: `https://github.com/open-telemetry/opentelemetry.io/pull/<num>`.

   Потім зупиніться, якщо ви також не залишаєте нотатки для рецензентів.

4. **Інакше** (якщо після кроку 2 залишилися записи, що не належать до кодів 2XX), перераховуйте залишкові URL-адреси та їх статуси:

   ```sh
   jq -r 'to_entries[] | select(.value.StatusCode < 200 or .value.StatusCode >= 300) | "\(.key) \(.value.StatusCode)"' \
     static/refcache.json
   ```

   > [!NOTE] URL LinkedIn
   >
   > Відповіді з `LinkedIn.com` часто ненадійні (агенти та боти можуть бачити 403 або 404 навіть тоді, коли профілі існують). **Не видаляйте** та не редагуйте посилання LinkedIn 4XX, натомість дозвольте підтримувачу вручну запустити `./scripts/double-check-refcache-4XX.mjs --retry-404` локально спочатку.

5. **Аналіз та рекомендації**. Для кожного URL з попереднього кроку створіть нумерований або маркований список, який включає принаймні:
   - URL та HTTP-статус.
   - Звідки він походить: надайте посилання на файли або сторінки.
   - Рекомендацію. Для посилань на github.com рекомендуйте заміну посилання на основі останнього коміту, що містить зазначений ресурс.

   Зачекайте відгуку від рецензента.

6. **Застосування затверджених виправлень.** Після затвердження редагуйте запропоновані джерела:
   - Для **404**, оновіть або видаліть посилання, де ви його виявили.
   - Для **інших статусів, що не належать до кодів 2XX**, застосуйте переглянуту рекомендацію (може знадобитися ручна перевірка для неоднозначних випадків).
   - Якщо будь-яка змінена сторінка знаходиться поза `content/en/`, дотримуйтесь рекомендацій зі сторінки [Локалізація](/docs/contributing/localization/#link-fixes-and-resource-updates) для цього редагування (наприклад, `# patched` на `default_lang_commit`).

7. Запустіть `npm run fix:refcache`, щоб оновити `static/refcache.json` після цих змін джерел посилань, а потім повторіть кроки в цьому розділі (з кроку 1), поки не залишиться статусів, що не належать до кодів 2XX.