Our first outside user hit an issue where he got his entrypoint working and published it, but then it was breaking when it was deployed. The entrypoint looked like this ...

@garden_entrypoint(
    metadata=entrypoint_meta, 
    model_connectors=[github_asr_connector],
    garden_doi=my_garden_doi
)
def predict_asr(comp_list, elec_list):
    import shutil, zipfile, sys, os
    download_path = github_asr_connector.stage()
    shutil.move('gh_model', 'ASR_model')
    with zipfile.ZipFile('ASR_model/Stability_model.zip', 'r') as zip_ref:
        zip_ref.extractall()

    shutil.move('Stability_model', 'ASR_model') 
    sys.path.append('ASR_model')
    os.system('pip install -r ASR_model/requirements.txt')   
    from model_predict_df import make_predictions
    preds = make_predictions(comp_list, elec_list) 
    return preds

On the first run it works fine. On subsequent runs it fails. zipfile.ZipFile('ASR_model/Stability_model.zip', 'r') complains that the directory it's trying to extract to already exists.

This shows that it's easy for users to shoot themselves in the foot with file operations or other non-idempotent operations in their entrypoint function. To mitigate this, we can hack the @test_function helper so that it runs an entrypoint twice. This will make sure that users see this problem in their code before publishing.

The fact that Garden does not wipe away the container environment between calls is also worth making clear in the docs somewhere.

Assumptions:

1. 2.

Acceptance Criteria

Given..., when..., then...

Garden-AI / garden

Make @test_function run twice to enforce idempotency of endpoints #424

Assumptions:

Acceptance Criteria