The Most Incredible Bug I Encounter: A Space Bar’s Costly Lesson on AWS EC2 Deployment of a Python Flask Project

Let me tell you about this wild bug I ran into while working on a project. I was using Python with Flask to build a website and got everything running smoothly on my own computer. So, naturally, I thought I was good to go and pushed it all to AWS EC2 for the world to see. That’s where things got interesting.

You know that feeling when everything works perfectly at home but then just falls apart when you show it off? That’s exactly what happened. My site worked like a charm locally, but as soon as I deployed it to AWS EC2, it just refused to cooperate. Talk about a nightmare, right? This is the kind of thing no one wants to deal with because it means there’s some tiny, annoying difference between your local setup and the server that you now have to hunt down.

So, here’s where I goofed up. First off, I made a bunch of changes all at once before deploying. Everyone says to change one thing at a time, so it’s easier to spot what breaks stuff. Well, I learned that lesson the hard way. I didn’t want to undo all my hard work, so I had to dig through my code line by line to figure out where I messed up.

My second mistake? I didn’t set up any logging online. This meant I had to tweak the code, redeploy, and then see what happened live. It was as fun as it sounds, which is to say, not fun at all.

But here’s the kicker: the whole problem came down to a single space. Yep, you heard that right. I had this piece of code where I was saving some data in a dictionary and then into a JSON file. Somehow, I left a space between a quote and a brace. My local setup didn’t care — it just shrugged and moved on. But AWS EC2? Nope, it threw a fit.

When I finally spotted that sneaky space, I was a mix of relieved and kicking myself. It was such a simple thing that caused so much trouble.

So, why am I sharing this? Well, I hope it saves you from your own space bar saga. It’s a funny story in hindsight, but it also shows how something small can lead to big headaches, especially when moving from local to the cloud. Keep an eye on those details!

By the way, ChatGPT told me that the reasons may be:

The only good news for me that day is that I decided to build an online log record function.

def configure_logging(app):
    project_root = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

    if os.getenv('IS_LOCAL'):
        log_file_path = os.path.join(project_root, '../logs_local/application.log')
    else:
        log_file_path = '/var/www/logs/application.log'

    log_file_path = os.path.normpath(log_file_path)
    
    # Ensure the log directory exists
    os.makedirs(os.path.dirname(log_file_path), exist_ok=True)

    # Create a file handler
    file_handler = RotatingFileHandler(log_file_path, maxBytes=1024 * 1024 * 100, backupCount=10)
    file_handler.setLevel(logging.INFO)
    formatter = logging.Formatter('%(asctime)s %(levelname)s: %(message)s [in %(pathname)s:%(lineno)d]')
    file_handler.setFormatter(formatter)

    # Set the logger level (adjust as needed)
    app.logger.setLevel(logging.INFO)

    # Attach the handler to the app's logger
    app.logger.addHandler(file_handler)

The above function shows that if it is in the local environment, then it will save log data in the “logs_local” file folder in the root path; and if it is in the AWS EC2, it will save the log in the path of ‘/var/www/logs/application.log’.

I use theIS_LOCAL parameter to tell the code what environment it is in. I saved:

IS_LOCAL = True

in the .env file, and don’t upload it to the AWS EC2.

In my code, I use the following code

from flask import current_app     
current_app.logger.error(f'Error for guest ID {guest_id}: {str(e)}')

to record error log.