Redis, a high-performance in-memory key-value store, is widely used for caching, session management, and various other scenarios where fast data retrieval is essential. One of its key features is the ability to set expiration times for keys. However, when using the SET command with the EX option, developers might encounter unexpected behaviors where the expiration time is seemingly lost. Let’s explore this issue in detail.

Understanding SET with EX

The Redis SET command with the EX option allows you to set a key’s value and specify its expiration time in seconds. For instance

SET key value EX 60

This command sets the key key to the value value and sets an expiration time of 60 seconds.

The Problem

In certain cases, the expiration time might be unexpectedly lost. This typically happens when subsequent operations overwrite the key without specifying a new expiration. For example,

SET key value1 EX 60
SET key value2

In the above sequence,

1. The first SET command assigns a value to key and sets an expiration of 60 seconds.
2. The second SET command overwrites the value of key but does not include an expiration time, resulting in the key persisting indefinitely.

This behavior can lead to subtle bugs, especially in applications that rely on key expiration for correctness or resource management.

Why Does This Happen?

The Redis SET command is designed to replace the entire state of a key, including its expiration. When you use SET without the EX, PX, or EXAT options, the expiration is removed, and the key becomes persistent. This behavior aligns with the principle that SET is a complete update operation.

When using Redis SET with EX, be mindful of operations that might overwrite keys without reapplying expiration. Understanding Redis’s behavior and implementing robust patterns can save you from unexpected issues, ensuring your application remains efficient and reliable.

Telegram Group: https://t.me/parottasalna

Github Repo: https://github.com/syedjaferk/daily_quiz_sender

In this blog, I’ll walk you through the journey of transitioning from a PythonAnywhere server to GitHub Actions for automating the delivery of daily quizzes to a Telegram group https://t.me/parottasalna . This implementation highlights the benefits of GitHub Actions to run a cronjob.

Problem Statement

I wanted to send a daily quiz to a Telegram group to keep members engaged and learning. Initially, I hosted the solution on a PythonAnywhere server.

Some of the limitations are,

1. Only one cron job is allowed for a free account.
2. For every x days, i need to visit the dashboard and reactive my account to make it work.

Recently, started learning the Github Actions . So thought of leveraging the schedule mechanism in it for my usecase.

Key Features of My Solution

• Automated Scheduling: GitHub Actions triggers the script daily at a specified time.
• Secure Secrets Management: Sensitive information like Telegram bot tokens and chat IDs are stored securely using GitHub Secrets.
• Serverless Architecture: No server maintenance; everything runs on GitHub’s infrastructure.

Implementation Overview

I am not explaining the code here. Please checkout the repo https://github.com/syedjaferk/daily_quiz_sender

The core components of the implementation include

1. A Python script (populate_questions.py) to create questions and store each question in the respective directory.
2. A Python script (runner.py) which takes telegram_bot_url, chat_id and category as input to read the correct question from the category directory and send the message.
3. A GitHub Actions workflow to automate execution.

Workflow Yaml File

name: Docker Quiz Sender

on:
  schedule:
    - cron: "30 4 * * *"

  workflow_dispatch:

jobs:
  run-python:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          if [ -f requirements.txt ]; then pip install -r requirements.txt; fi

      - name: Run script with secrets0
        run: python runner.py --telegram_url ${{ secrets.TELEGRAM_BOT_URL }} --chat_id ${{ secrets.CHAT_ID }} --category docker

Benefits of the New Implementation

1. Cost-Effectiveness: No server costs thanks to GitHub’s free tier for public repositories.
2. Reliability: GitHub Actions ensures the script runs on schedule without manual intervention.
3. Security: GitHub Secrets securely manages sensitive credentials.
4. Centralization: All code, configuration, and automation reside in a single repository.

Lessons Learned

• Environment Variables: Using environment variables for secrets keeps the code clean and secure.
• Error Handling: Adding error-handling mechanisms in the script helps debug issues effectively.
• Time Zones: GitHub Actions uses UTC; be mindful when scheduling tasks for specific time zones.

Future Enhancements

1. Dynamic Quizzes: Automate quiz generation from a database (sqlite3) or external API.
2. Logging: Store logs as GitHub Actions artifacts for better debugging and tracking.
3. Failure Notifications: Notify via Telegram or email if the workflow fails.
4. Extend for other categories

You can check out the project here. Feel free to fork it and adapt it to your needs!