Skip to content

Internal cache name not updated for CACHE_FALLBACK_KEY after manually clearing cache

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

After clearing the cache manually, the internal cache name is updated. When using a fallback cache key though, that key still references the old version without the index appended.

For example, when using a fallback cache with the name 'cache' and after clearing the cache manually, all cache keys now use 'cache-1', except for any fallback caches set using CACHE_FALLBACK_KEY, which still try to use 'cache' as the cache key.

Steps to reproduce

Add the following to the gitlab-ci.yml;

stages:
  - repro
  - cache

repro:
    stage: repro
    script:
      - touch foo.bar
    cache:
      - key: "$CI_COMMIT_REF_SLUG-repro"
        paths:
          - foo.bar
        policy: pull-push
        when: always
    variables:
      CACHE_FALLBACK_KEY: fallback


update-fallback:
  stage: cache
  only:
    - master
  needs:
    - job: repro
  cache:
    - key: "$CI_COMMIT_REF_SLUG-repro"
      paths:
        - foo.bar
      policy: pull
    - key: fallback
      paths:
        - foo.bar
      policy: push

Make sure the job runs on master.

After manually clearing the cache, any new run on master will push to the cache key 'fallback-1' instead of 'fallback', but new branches that don't have a branch cache still use the fallback cache key 'fallback', where it should be 'fallback-1'

Example Project

What is the current bug behavior?

When using a CACHE_FALLBACK_KEY, the internal cache name is not updated after manually clearing the cache.

What is the expected correct behavior?

After clearing the cache manually, the internal cache name is appended by a dash and the new cache index, just as with non fallback cache keys.

Relevant logs and/or screenshots

Fallback cache creation:

Saving cache for successful job
00:12
Not uploading cache master-repro-3 due to policy
Creating cache fallback-3...
phpstan-result-cache: found 1 matching files and directories 
Uploading cache.zip to ########REDACTED####### 
Created cache

Cache retrieval with fallback key:

Restoring cache
00:12
Checking cache for branch-name-repro...
FATAL: file does not exist                         
Failed to extract cache
Checking cache for fallback...
FATAL: file does not exist

Notice that the cache is uploaded for the key 'fallback-3', but retrieved from 'fallback'

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 

System information
System:         Ubuntu 20.04
Current User:   git
Using RVM:      no
Ruby Version:   2.7.5p203
Gem Version:    3.1.4
Bundler Version:2.1.4
Rake Version:   13.0.6
Redis Version:  6.2.6
Sidekiq Version:6.4.0
Go Version:     unknown

GitLab information
Version:        14.8.1
Revision:       479d579719c
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     PostgreSQL
DB Version:     12.7
URL:            https://###REDACTED###
HTTP Clone URL: https://###REDACTED###/some-group/some-project.git
SSH Clone URL:  git@###REDACTED###:some-group/some-project.git
Using LDAP:     no
Using Omniauth: yes
Omniauth Providers: 

GitLab Shell
Version:        13.23.2
Repository storage paths:
- default:      /var/opt/gitlab/git-data/repositories
GitLab Shell path:              /opt/gitlab/embedded/service/gitlab-shell

Results of GitLab application Check

Expand for output related to the GitLab application check 
Checking GitLab subtasks ...


Checking GitLab Shell ...


GitLab Shell: ... GitLab Shell version >= 13.23.2 ? ... OK (13.23.2)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful


Checking GitLab Shell ... Finished


Checking Gitaly ...


Gitaly: ... default ... OK


Checking Gitaly ... Finished


Checking Sidekiq ...


Sidekiq: ... Running? ... yes
Number of Sidekiq processes (cluster/worker) ... 1/1


Checking Sidekiq ... Finished


Checking Incoming Email ...


Incoming Email: ... Reply by email is disabled in config/gitlab.yml


Checking Incoming Email ... Finished


Checking LDAP ...


LDAP: ... LDAP is disabled in config/gitlab.yml


Checking LDAP ... Finished


Checking GitLab App ...


Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Systemd unit files or init script exist? ... skipped (omnibus-gitlab has neither init script nor systemd units)
Systemd unit files or init script up-to-date? ... skipped (omnibus-gitlab has neither init script nor systemd units)
Projects have namespace: ...
2/1 ... yes
7/2 ... yes
7/3 ... yes
7/4 ... yes
7/5 ... yes
7/6 ... yes
7/7 ... yes
7/8 ... yes
7/9 ... yes
7/10 ... yes
7/11 ... yes
7/12 ... yes
7/13 ... yes
3/14 ... yes
3/15 ... yes
7/16 ... yes
7/17 ... yes
7/18 ... yes
7/21 ... yes
Redis version >= 5.0.0? ... yes
Ruby version >= 2.7.2 ? ... yes (2.7.5)
Git user has default SSH configuration? ... yes
Active users: ... 10
Is authorized keys file accessible? ... yes
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes


Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished

Possible fixes

Related issues

Another issue already exists here, but without a repro and without debugging info so I made a new one. (#335572 (closed))

Edited by 🤖 GitLab Bot 🤖